Re: Call virtual function in constructor
In C++ this is dealt with by constructors, which, as opposed to
other member functions, operate on not-yet-initialized objects.
This is not true. The Standard allows calling "other member
functions" from the constructor and these functions operate on
not-yet-initialized objects with pre-determined results -- even
virtual functions -- unless the virtual call "uses an explicit class
member access". So, the Standard is OK with the member functions
operating on not-yet-initialized object.
[counter to that + some context was snipped, see up-thread]
I think choosing such a silly interpretation is a bit adversarial.
Again, no pun was intended. I simply do not know how else to interpret
your "constructors, as opposed to other member functions, operate on
not-yet-initialized objects". If a constructor calls another member
function why can not that function operate on "not-yet initialized
object"? Does not it make your statement not true?
First, just to recap some of what you snipped, an init-function is an
example of a function that does that, technically.
And a statement is not untrue just because there exists a possible
Think about calls from client code.
In particular, even a private virtual function can be called in client
code that derives from the class in question, and that client code
implementation can then very easily see an uninitialized *this object.
And the other way, it might end up calling other functions that the
client code overrides.
But note that that problem is not /that/ severe in Java because Java
also has another severe problem -- non-deterministic not-guaranteed
destruction -- that often necessitates a two-level class invariant
(object is zombie OR real class invariant) and ditto peppering of checks
of whether the meta-level of being a zombie object, holds, so that
preventive checking of whether the object is a zombie object, in every
member function, isn't necessarily an extra cost, just usual Java...
In passing, check out <url:
Cheers, & hth.,
 That bug report refers to a blog that provides a "solution" that
doesn't work for multiple levels of inheritance, and that relies on
documentation instead of compiler enforcement, best ignored, or perhaps
taken as evidence that at least one blogging Java programmer and one
Java bug report responder do not grok the complete picture.
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
Q: What is the most annoying thing on usenet and in e-mail?