Final and Cieled and nothing in C++

  • Thread starter My4thPersonality
  • Start date
M

My4thPersonality

Has the fact that both Java and C# are garbage collected, and C++ in not,
anything to do with the fact that there is no language item to prevent a
class from being inherired from? I once read that Java and C# implement this
feature for preformance, but the C++ creators said it was not worse the
effort. So because Java and C# are garbage collected, in their case is it
worse the effort? What is the connection?
 
A

Alex Blekhman

My4thPersonality said:
Has the fact that both Java and C# are garbage collected,
and C++ in not, anything to do with the fact that there
is no language item to prevent a class from being
inherired from? I once read that Java and C# implement
this feature for preformance, but the C++ creators said
it was not worse the effort. So because Java and C# are
garbage collected, in their case is it worse the effort?
What is the connection?

"Why doesn't C++ have garbage collection?"
http://www.research.att.com/~bs/bs_faq.html#garbage-collection
 
B

Bo Persson

My4thPersonality said:
Has the fact that both Java and C# are garbage collected, and C++ in
not, anything to do with the fact that there is no language item to
prevent a class from being inherired from? I once read that Java and
C# implement this feature for preformance, but the C++ creators said
it was not worse the effort. So because Java and C# are garbage
collected, in their case is it worse the effort? What is the
connection?

It is not about garbage collection, it is about vitual functions. In
C++, a function isn't virtual, unless you specifically make it so.
That pretty much removes the need to specify 'final' to make the
functions non-virtual again - just don't make it virtual in the first
place!

Also, you can prevent a C++ class from being inherited from, but
making its constructor private. This isn't used very much though. The
usual way is to add a note in the documentation, "This class isn't
designed for inheritance".


Bo Persson
 
C

Carl Daniel [VC++ MVP]

Bo said:
It is not about garbage collection, it is about vitual functions. In
C++, a function isn't virtual, unless you specifically make it so.
That pretty much removes the need to specify 'final' to make the
functions non-virtual again - just don't make it virtual in the first
place!

Also, you can prevent a C++ class from being inherited from, but
making its constructor private. This isn't used very much though. The
usual way is to add a note in the documentation, "This class isn't
designed for inheritance".

That said, final/sealed would be useful in C++ as an optimization, since
they allow the compiler to easily determine the final overrider of a virtual
function in some useful cases without doing whole program analysis. I think
that many C++ programmers would welcome the ability to mark a class as "not
inheritable". It's a common enough situation, and the idioms used to
prevent it in C++ are hacks at best, not proper language features. Easy to
get along without, yes, but still nice to have.

-cd
 
M

marcwentink

In C++, a function isn't virtual, unless you specifically make it so.

And in Java and C# a function is virtual by default?
 
M

marcwentink

Jon

In Java it is. In C# it isn't.

Mmm...

Do both languages, Java and C#, actually have functions that are not
members of a class? They have not have they?
 
J

Jon Skeet [C# MVP]

Mmm...

Do both languages, Java and C#, actually have functions that are not
members of a class? They have not have they?

Assuming you mean "methods which are not members of a type" - no. (I'm
being picky - "function" isn't a C# term, but structs *can* have
methods. I suspect we're on the same wavelength, but it's worth
clarifying just for the sake of posterity :)

Personally I wish that classes were sealed by default in C#, but then I
view inheritance as something to be used sparingly. (It's wonderful
where it *is* useful.)

Jon
 
M

marcwentink

Sorry, I couldn't understand what you wanted to say.

Euh, well, I understand, follow the explination of Bjarne Stroustrup
that final has too little use to implement because the performance gain
in C++ would be little. But then I ask myself, why would the
performance gain in Java would be substantional.

"In C++, virtual function calls are so fast that their real-world use
for a class designed with virtual functions does not to produce
measurable run-time overheads compared to alternative solutions using
ordinary function calls."

Hence somehow, virtual functions in Java are slow and finalized
function a lot faster? Or it just a mre or less coincidental choice the
developers of both language decided to do and not do. By the way, I am
more in C++ then in Java and or C#, but I am studying the latter two
languages to broaden my knowledge.
 
A

Alex Blekhman

Euh, well, I understand, follow the explination of Bjarne
Stroustrup that final has too little use to implement
because the performance gain in C++ would be little.

No, B.Stroustrup mentions two common arguments of `final'
proponents. One is possible performance gain (when callin
virtual functions), second is safety (to prevent unwanted
derivation).
Hence somehow, virtual functions in Java are slow and
finalized function a lot faster? Or it just a mre or less
coincidental choice the developers of both language
decided to do and not do.

I don't think that `final' concept exists in Java solely
because of performance considerations. Moreover, I reckon
that performance has very little part in `final' argument.
It exists to provide class hierarchy designers with means to
ensure logic correctness. By applying `final' specifier
function doesn't cease to be "virtual" (as we understand it
in C++). It merely prevents farther derivations/overloading.
"Virtuality" still works until it finds final derivative.
 
B

Bo Persson

Euh, well, I understand, follow the explination of Bjarne Stroustrup
that final has too little use to implement because the performance
gain
in C++ would be little. But then I ask myself, why would the
performance gain in Java would be substantional.

Because in C++ functions are not virtual by default, so the use for
final is limited.
"In C++, virtual function calls are so fast that their real-world
use
for a class designed with virtual functions does not to produce
measurable run-time overheads compared to alternative solutions
using
ordinary function calls."

On C++, a function is virtual only if explicitly made so. That
probably is part of the interface design for subclasses, so there is s
genuine need for the function to be virtual.

Again, the few exceptions from this doesn't make it worthwhile to
introduce a new concept. A small gain in very few places. Is it worth
it?
Hence somehow, virtual functions in Java are slow and finalized
function a lot faster? Or it just a mre or less coincidental choice
the
developers of both language decided to do and not do. By the way, I
am
more in C++ then in Java and or C#, but I am studying the latter two
languages to broaden my knowledge.

There are a lot more vitual functions in Java, so there are more
opportunities for finalizing functions. I also suspect that early Java
systems didn't optimize as well as C++ compilers can do. Perhaps the
gain used to be greater?


Bo Persson
 
M

marcwentink

Alex:
Because in C++ functions are not virtual by default, so the use for
final is limited.

Ok, so in C++ I just do not declare a function as virtual, while in
Java I explicitly declare it final because it is java-virtual by
default. Hence considering functionality I already got an alternative
in C++.

I thank you and Bo, and the others for the explination. It's clearer
now.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top