Final and Cieled and nothing in C++

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?

Alex
Sun Feb 05 04:10:56 CST 2006

My4thPersonality wrote:
> 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

Bo
Sun Feb 05 06:18:00 CST 2006


"My4thPersonality" <somewhere@out.there> skrev i meddelandet
news:u2UKpqiKGHA.952@TK2MSFTNGP10.phx.gbl...
> 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

Carl
Sun Feb 05 09:31:35 CST 2006

Bo Persson wrote:
> "My4thPersonality" <somewhere@out.there> skrev i meddelandet
> news:u2UKpqiKGHA.952@TK2MSFTNGP10.phx.gbl...
>> 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".

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

marcwentink
Mon Feb 06 02:36:14 CST 2006

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

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

Mark
Mon Feb 06 06:48:55 CST 2006

<marcwentink@hotmail.com> wrote:
> And in Java and C# a function is virtual by default?

Yes

Jon
Mon Feb 06 07:21:30 CST 2006

marcwentink@hotmail.com wrote:
> > In C++, a function isn't virtual, unless you specifically make it so.
>
> And in Java and C# a function is virtual by default?

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

Jon

marcwentink
Tue Feb 07 03:05:48 CST 2006


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

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?

Jon
Tue Feb 07 03:08:53 CST 2006

marcwent...@hotmail.com wrote:
> > 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?

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

marcwentink
Tue Feb 07 03:51:05 CST 2006

Alex Blekhman:

> http://www.research.att.com/~bs/bs_faq.html#garbage-collection

More relevant would be this then:

"Why doesn't C++ have a final keyword?"

http://public.research.att.com/~bs/bs_faq2.html

But then, why would the lack of performance gain be relevant in Java,
but not relevant in C++.

Alex
Tue Feb 07 05:55:32 CST 2006

marcwentink@hotmail.com wrote:
> Alex Blekhman:
>
>> http://www.research.att.com/~bs/bs_faq.html#garbage-collection
>
> More relevant would be this then:
>
> "Why doesn't C++ have a final keyword?"
>
> http://public.research.att.com/~bs/bs_faq2.html

Agree.

> But then, why would the lack of performance gain be
> relevant in Java, but not relevant in C++.

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

marcwentink
Tue Feb 07 07:01:51 CST 2006

> 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.

Alex
Tue Feb 07 08:26:45 CST 2006

marcwentink@hotmail.com wrote:
>> 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.

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.

Bo
Tue Feb 07 10:10:30 CST 2006


<marcwentink@hotmail.com> skrev i meddelandet
news:1139314499.894197.124200@g14g2000cwa.googlegroups.com...
>> 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.

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

marcwentink
Wed Feb 08 03:06:21 CST 2006

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.