Re: A few minor questions
On May 19, 4:48 am, "Alf P. Steinbach" <al...@start.no> wrote:
* blargg:
You cannot call constructors;
Of course one can, and that's the terminology employed both in
practical programming and by the standard.
Here we go again:-).
You've actually hit the nail on the head this time: it's
terminology. The problem is that "to call a constructor" (when
it's the programmer who does the calling) means different things
in different contexts.
-- At the language level, there is no expression syntax to
"call a constructor" (i.e. in the way there is a "pseudo
destructor call" syntax). When someone says that "you can't
call a constructor" in C++, this is generally what they
mean---there is no expression syntax which calls a
constructor, and does nothing but call a constructor.
-- In practice, of course, constructors get called:-). And
they get called because of things the programmer has
written. When someone speaks about the programmer "calling
a constructor", what they generally mean is that the
programmer has intentionally used a some construct which he
knows will result in the constructor being called (along
with, usually, the memory for the object being allocated).
Because of possible confusion, I prefer calling this
"creating an object", but the expression "call a
constructor" is certainly widely used in this sense
(including, as you point out, a couple of places in the
standard).
-- If I'm writing low level code, I may want to separate
allocation and initialization. In this case, I might speak
of "calling the constructor" as a shorthand for using a
placement new. This is really a more or less advanced
technique, however, and I don't think it is relevant to the
original poster.
I presume that the original poster was using the expression in
the second sense. In the context of his question, however, I
would avoid the expression "you call the constructor", because I
think what is important is that anytime the constructor of a
derived class is called (regardless of who does the calling or
why), the constructor of the base class is called first. The
use of the active form, "you call the constructor" might suggest
that there are cases when something else calls the constructor,
when this might not be true.
the compiler does it as a part of constructing an object.
I think you mean that the compiler generates machine code (or
other executable code such as byte code) that calls a
constructor.
I think he probably means that the abstract machine in the
standard calls the constructor. What this translates to in
machine code depends on the compiler, and the degree of
optimization.
And that is partially correct.
A source code constructor call may however not necessarily be
translated to an actual machine code call.
Now I'm not sure what you're talking about. What exactly do you
mean by "a source code constructor call"? One particular
expression construct, defined in section 5? Or anything in the
source code which is defined to result in a constructor call in
the abstract machine? And is your point the fact that the
compiler may generate the constructor inline (even if it isn't
declard inline), or that it has explicit authorization to
suppress certain copies (which results in the constructor of the
copy being suppressed)? Or even a more liberal application of
the "as if" rule: if you define an object with a trivial
destructor, or whose destructor has no effect on "observable
behavior", the compiler can eliminate it, since eliminating it
has no effect on observable behavior.
When constructing an object, the compiler never calls more
than one constructor for a given class.
That's literally meaningless, but I think you mean, "the
generated machine code" rather than "the compiler".
And if so then that's very incorrect.
Most of all, it's very incorrect. The compiler always
"constructs" each sub-object exactly once. If there are several
sub-objects of the same (class) type, then the compiler will
call the constructor of this type several times.
(For the rest, I'm interpreting "the compiler calls the
constructor" to mean: the standard specifies that the abstract
machine will call the constructor.)
But a correct description of it all, including calls to base
class constructors, the case of virtual inheritance, C++0x
constructor call forwarding, and the whole shebang, would be
long.
I think you could do in in a single page (DIN A4). It's about
the limit of the acceptable posting size, but more to the point,
anyone who asks this sort of question probably needs a lot more
information as well, and should consult a more complete
description.
A constructor cannot be virtual, since it creates an object
out of storage where there was none before.
I'm sorry but that's again incorrect, a misguided
rationalization. The reason that a constructor cannot be
declared "virtual" in C++ is because the language is designed
that way. As discussed ad nauseam before it's not at all
difficult to find reasonable and useful semantics for a
virtual-declared constructor, and indeed standard terms such
as "virtual constructor" (see the FAQ) wouldn't exist if such
reasonable and practically useful semantics did not exist.
Again, "virtual" can have different meanings in different
contexts. A constructor cannot be virtual in the sense of the
language standard, since the language standard defines virtual
resolution to involve the dynamic type of the existing object.
When we speak of a "virtual constructor", we are talking of
something that isn't just a constructor (in the strict sense of
the language). (Which doesn't mean that the language couldn't
have provided for it in some way.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34