virtual member

[worlman385]

How is C++'s virtual member compare to Java?

does Java has virtual function?

like the following, what's different to have methods declare virtual
VS non-virtual?

#########################
Public Member Functions
virtual ~IInterfaceElement ()
IInterfaceElement ()
void SetContainer (CContainer *pParentContainer)
virtual void Initialize ()
virtual void Update ()
virtual void Draw ()
virtual void Release ()
virtual void SetZOrder (float fZOrder)
virtual float GetZOrder ()
virtual bool IsInitialized ()

 

[EventHelix.com]

How is C++'s virtual member compare to Java?

does Java has virtual function?

like the following, what's different to have methods declare virtual
VS non-virtual?

#########################
Public Member Functions
virtual         ~IInterfaceElement ()
        IInterfaceElement ()
void    SetContainer (CContainer *pParentContainer)
virtual void    Initialize ()
virtual void    Update ()
virtual void    Draw ()
virtual void    Release ()
virtual void    SetZOrder (float fZOrder)
virtual float   GetZOrder ()
virtual bool    IsInitialized ()

In Java all methods are virtual by default.

 

[pelio]

EventHelix.com dixit:

In Java all methods are virtual by default.

"by default" ? is there a way to have a method non-virtual in java ?

 

[James Kanze]

EventHelix.com dixit:

Virtual functions are resolved at run-time, according to the
dynamic type of the object. Non-virtual functions are resolved
at compile time, according to the static type of the object.

That's not true. In Java, private functions are never virtual.
(Of course, in most cases, the only functions you want virtual
are the private ones.)

"by default" ? is there a way to have a method non-virtual in
java ?

It depends on what you mean. You can declare a function final,
in which case, it can't be overridden in a derived class.

Logically, there are two different aspects involved: the
function overrides a function in a base class, and the function
can be overridden in a derived class. In C++, the virtual
keyword affects the function being declared, saying it can be
overridden; it also affects all of the overriding functions in
the derived classes, saying that they too can be overridden. In
Java, the final modifier says that the function cannot be
overridden in any derived class; it may still override a
function in a base class (which means that it's still virtual).

 

[Christian Hackl]

That's not true. In Java, private functions are never virtual.
(Of course, in most cases, the only functions you want virtual
are the private ones.)

The FAQ says you should avoid private virtual functions [1]. I usually
don't go by this advice and use them anyway, but I often wonder if
that's really the correct approach. Could you share some thoughts on
this issue? Do you think that the confusion argument explained by the
FAQ in favor of protected virtuals does not hold?


[1]
<URL:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>

 

[Ron Natalie]

That's not true. In Java, private functions are never virtual.
(Of course, in most cases, the only functions you want virtual
are the private ones.)

The FAQ says you should avoid private virtual functions [1]. I usually
don't go by this advice and use them anyway, but I often wonder if
that's really the correct approach. Could you share some thoughts on
this issue? Do you think that the confusion argument explained by the
FAQ in favor of protected virtuals does not hold?


[1]
<URL:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>

The reasoning given in the FAQ is one of the stupidest I've ever seen.

 

[Christian Hackl]

The FAQ says you should avoid private virtual functions [...]

<URL:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>

The reasoning given in the FAQ is one of the stupidest I've ever seen.

So in your projects you've never personally had the "confusion" problem
it refers to? Not that it sounds very convincing to me, either... but
then again, I've never really worked on what could be considered a
large-scale project in C++ -- while the author of the FAQ obviously did
-- so I wonder what other experienced developers think about it.

 

[Kai-Uwe Bux]

The FAQ says you should avoid private virtual functions [...]

The reasoning given in the FAQ is one of the stupidest I've ever seen.

So in your projects you've never personally had the "confusion" problem
it refers to? [snip]

Sure one gets confused the first time one sees it, but that does not save
the reasoning of the FAQ. I would maintain that one gets much more confused
the first time one runs into templates or dependent name issues. Is that a
reason to "almost never" use templates? (Not that there are no reasons to
avoid templates, but the danger to confuse someone is probably pretty much
far down the list.) The reasoning in the FAQ is just bogus since along the
lines of such reasoning you could prove that each and every single feature
of C++ should be used "almost never" which then just shows that you
should "almost always" use a different language


Best

Kai-Uwe Bux

 

[Christian Hackl]

The FAQ says you should avoid private virtual functions [...]

So in your projects you've never personally had the "confusion" problem
it refers to? [snip]

Sure one gets confused the first time one sees it, but that does not save
the reasoning of the FAQ. I would maintain that one gets much more confused
the first time one runs into templates or dependent name issues. Is that a
reason to "almost never" use templates?

Thanks for sharing your opinion.

So, if the consensus is that this item in the FAQ is wrong, then why
isn't it just removed?

 

[James Kanze]

The FAQ says you should avoid private virtual functions [1].

In this case, the FAQ is wrong. The generally accepted practice
is that virtual functions should usually be private. To the
point that it's often overdone; people make the virtual
functions private even when the motivating reasons don't apply.
(I don't make them private when there's an inversion of the call
sequence, e.g. in things like the visitor pattern.)

I usually don't go by this advice and use them anyway, but I
often wonder if that's really the correct approach. Could you
share some thoughts on this issue? Do you think that the
confusion argument explained by the FAQ in favor of protected
virtuals does not hold?

I think the fact that some of the established "references"
recommend making them private pretty much creates the
expectation that they be private. There is an argument for
protected, of course---it emulates closer the way Eiffel works
with regards to programming by contract (where a derived class
is allowed to violate pre- and post-conditions and invariants).
My feeling is that in the case, Eiffel got it wrong, but I
wouldn't say that it's a cut and dry issue.

 

[James Kanze]

Ron Natalie schrieb:

Christian Hackl wrote:

The FAQ says you should avoid private virtual functions [...]
<URL:http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>

The reasoning given in the FAQ is one of the stupidest I've ever seen.

So in your projects you've never personally had the
"confusion" problem it refers to? Not that it sounds very
convincing to me, either... but then again, I've never really
worked on what could be considered a large-scale project in
C++ -- while the author of the FAQ obviously did -- so I
wonder what other experienced developers think about it.

I have worked on large projects. Some very large, in fact (over
150 programmers). We still expected all of the programmers to
be familiar with the standard texts.

The problem is probably less in large projects, because in a
large project, you'll always have one or two experts available
for mentoring, and you'll have written coding guidelines which
explain when and why virtual functions should be private. If
there is a problem, it would be in the small, unorganized
projects where there is a high turn over. But personally, I
don't see it.

 

[Christian Hackl]

Christian Hackl wrote:

The FAQ says you should avoid private virtual functions [...] >

I have worked on large projects. Some very large, in fact (over
150 programmers). We still expected all of the programmers to
be familiar with the standard texts.

The problem is probably less in large projects, because in a
large project, you'll always have one or two experts available
for mentoring, and you'll have written coding guidelines which
explain when and why virtual functions should be private. If
there is a problem, it would be in the small, unorganized
projects where there is a high turn over. But personally, I
don't see it.

Well, I'm glad I haven't got used to the wrong way of doing things,
then. Thanks to you, too

 

[Erik Wikström]

The FAQ says you should avoid private virtual functions [...]

So in your projects you've never personally had the "confusion" problem
it refers to? [snip]

Sure one gets confused the first time one sees it, but that does not save
the reasoning of the FAQ. I would maintain that one gets much more confused
the first time one runs into templates or dependent name issues. Is that a
reason to "almost never" use templates?

Thanks for sharing your opinion.

So, if the consensus is that this item in the FAQ is wrong, then why
isn't it just removed?

Perhaps Marshall Cline (the maintainer of the FAQ) does not share the
opinion about the argument being bogus.

 

[Ron Natalie]

Perhaps Marshall Cline (the maintainer of the FAQ) does not share the
opinion about the argument being bogus.

Yes, you should realize the FAQ is not some cooperative function
of the group but Marshall's personal business venture primarily
as a teaser to promote his book.

By and large it's pretty good and it gives group members a place
to point people by reference and not have to regurgitate common
issues over and over again.

 

[James Kanze]

Erik Wikström wrote:

Yes, you should realize the FAQ is not some cooperative
function of the group but Marshall's personal business venture
primarily as a teaser to promote his book.

I don't think that that's the original motivation; the FAQ was
around long before he brought it out as a book (and I doubt that
any additional sales because of it will really make a
significant financial difference for Marshall---I don't think
technical books are big money makers, even when they are "best
sellers").

As for "cooperative venture", the purported role of FAQs is to
express a concensus, not the author's personal opinion. In this
case, I think that Marshall has overstepped his role as author,
since his point of view here is certainly NOT a concensus among
C++ experts. But I guess he's human, like the rest of us, and
he's certainly not the only FAQ author who's done this. As far
as I know, there are very, very few such cases of this in the
C++ FAQ. (This is the only one I actually know of.) And I
don't know of any other document that is perfect, either.