Initialization of numeric (intrinsic type) data members

This always confuses me. In the example below I would like x to be zero-
initialised on default construction of a struct A object (there is no
other initialisation/construction code required for default
construction). Which form is most appropriate?

struct A
{
double x;

// first form
// No user-supplied default constructor

// second form
A() {}

// third form
A() : x() {}

// fourth form
A() : x(0.0) {}
};

void foo()
{
A a;
/* do stuff, assuming a.x == 0.0 */
}

Could some kind soul also point me to the relevant entry in the standard?

Thanks,

--
Lionel B

re: Initialization of numeric (intrinsic type) data members

On Tue, 17 Jul 2007 10:51:49 +0000, Neelesh Bodas wrote:
Right. I actually use the third form in the "real" code (the numeric type
is in fact a template argument).
[...]

Thanks very much,

--
Lionel B

re: Initialization of numeric (intrinsic type) data members

On Jul 17, 12:03 pm, Lionel B <m...@privacy.netwrote:Does nothing...
Does nothing...
Either "value initializes" or "default initializes" x, according
to which version of the standard you refer to. In the case of a
POD type like double, there's no difference, however; both mean
that x will be "zero initialized" (which is the equivalent of
"x(0)"; i.e. it initializes the value with the results of
converting the integral constant 0 to the appropriate type).

This features was added in the 1998 standard; it wasn't present
in pre-standard C++, and some very old compilers might not
implement it. (In pre-standard C++, it did nothing, like the
two previous versions.)
Initializes x with 0.0. If that's what you want, then this is
the most appropriate form. (The "x()" form might be more
appropriate, of course, for more complicated types, or in a
template.)
Which version of the standard:-)? The different types of
initialization are described in detail in §8.5, from about
paragraph 5 on. The details do differ depending on the version
of the standard, however. (I think the difference is really
only relevant for class types with non-trivial compiler
generated constructors, but I wouldn't swear to it.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: Initialization of numeric (intrinsic type) data members

James Kanze wrote:For some freaky reason, in *my* twisted understanding of the
standardisation process, there is always one and only Standard.
Why muddy the waters by the terms like "version of the standard"
when any earlier "version" is *always* superceded by the later
"version"? Yes, one can always find the Gloekenspiel C++ (or
however it was called) and try using it, but it's not the matter
of "version of the standard" but rather of compliance to _the_
Standard (which BTW has already been in force for ~4 years now).
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

re: Initialization of numeric (intrinsic type) data members

On Jul 18, 2:22 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:In theory, you're right. But the one today isn't the same as
the one yesterday, and compilers vary with regards to which one,
if any, they support.
Because in practice, it isn't.
The official version is C++ 2003. Regretfully, I don't have
that version handy. And g++ only accepts -std=c++98---it
doesn't support the changes introduced in 2003. And I would
imagine that most people would prefer code that won't suddenly
be broken when the next version of the standard appears
(promessed before 2009, but I really don't think that's
possible), so what the current draft says isn't without interest
either.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34