In article <slrn.pl.9i2f79.eb2.qrczak@qrnik.zagroda>, Marcin 'Qrczak'
Kowalczyk <qrczak@knm.org.pl> writes
>> The destruction sequence is defined as the reverse of the
>> construction sequence,
>
>What for?

would you prefer that it was arbitrarily defined? Reverse order is least
likely to break on inter-type dependencies.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B207BDB.9A5AAA2F@aixigo.de>, Daniel Frey says...

[ SNIP ]

>While we are at it: I sometimes forget to initialize a member variable
>if I have large classes and several ctors. Would it make sense to allow
>declaring a member variable as 'explicit', meaning you have to provide
>it for all ctors? For example:
>
>class A
>{
>private:
>   explicit std::string text;
>
>public:
>   A() : text( "Hallo" ) {} // OK
>   A( std::string s ) {} // Error, no initializer for 'text'
>};
>Regards, Daniel

I don't think that makes sense. 's' is initialized, to the empty string.
If the domain of 's' does not include the empty string you should use
another class - most likely a trivial wrapper around std::string, but
one that makes sure that .size() >0

In general if you want to have a member which requires initialization,
use a type without a default ctor. So there is no need for 'explicit'
in the context you provide.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Wei Ku wrote:
>=20
> Hello, all:
>=20
> Is the order of initialization of member variables determined by the or=
der
> they appear in the initialization list of the constructor, or by the or=
der
> they appear in the declaration of the class ?  For, example,

The latter, as the other answers already told you. To remember this
rule, it helps to understand the reason: If variables depend on each
other during construction/initialization, they could also depend during
destruction. The destruction sequence is defined as the reverse of the
construction sequence, but how can the compiler know it if you could
vary the order of initialization? If you have multiple constructors, the
compiler has to remember the order for each object and this is an
overhead you'd usually not be aware of and you don't want to have.
Therefore, the order of initialization is given by the declaration
order. (Some of this stuff may sound weird as I'm not very good in
english, but I hope you get the idea anyway :)

While we are at it: I sometimes forget to initialize a member variable
if I have large classes and several ctors. Would it make sense to allow
declaring a member variable as 'explicit', meaning you have to provide
it for all ctors? For example:

class A
{
private:
   explicit std::string text;

public:
   A() : text( "Hallo" ) {} // OK
   A( std::string s ) {} // Error, no initializer for 'text'
};

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Thanks for the very useful explanation.

Wei

>The latter, as the other answers already told you. To remember this
>rule, it helps to understand the reason: If variables depend on each
>other during construction/initialization, they could also depend during
>destruction. The destruction sequence is defined as the reverse of the
>construction sequence, but how can the compiler know it if you could
>vary the order of initialization? If you have multiple constructors, the
>compiler has to remember the order for each object and this is an
>overhead you'd usually not be aware of and you don't want to have.
>Therefore, the order of initialization is given by the declaration
>order. (Some of this stuff may sound weird as I'm not very good in
>english, but I hope you get the idea anyway :)



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Fri,  8 Jun 2001 20:05:31 GMT, Daniel Frey <daniel.frey@aixigo.de> pisze:

[...]
> The destruction sequence is defined as the reverse of the
> construction sequence,

What for?

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Marcin 'Qrczak' Kowalczyk wrote:
>
> Fri,  8 Jun 2001 20:05:31 GMT, Daniel Frey <daniel.frey@aixigo.de> pisze:
>
> [...]
> > The destruction sequence is defined as the reverse of the
> > construction sequence,
>
> What for?

The basic reason is that if one object was constructed after another,
there's a chance that they might be connected - the second object's
destructor might depend upon the first object still being in existence.
By establishing this rule, code which works that way has well-defined
behavior; without this rule, such code is impossible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]