On 19 Jun 2002, Robert Monroe wrote:
>
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<D5GO8.7488$Nq6.626619602@newssvr13.news.prodigy.com>...
> > "Krzysztof Parzyszek" <kristof@swissmail.org> wrote in message
> > news:ugle1h8haa1jcd@corp.supernews.com...
> > > So, my question is:  does the standard mandate that whatever the order
> > > of initialization of all global objects is in a given case, the order
> > > of destruction is guaranteed to be the opposite?
> >
> > Precisely so.
> > -cd
>
> This is interesting. It is something I was not aware of. I have tried
> to imagine a case where it would be of value to know this rule about
> the order of destruction.

The construction of a static object y might depend on another static
object x. The destruction of y might also depend on x still existing:
 #include "Lock.h" // class Lock
 extern Lock x;
 struct B {
  B() { x.lock(); ... }
  ~B() { x.unlock(); ... }
  ...
 } y;

Even if you know that x will be constructed before y, you can't
write this code unless you know that x won't be destroyed
before y.

But if x is constructed first, it cannot depend on y.

Therefore, it is always safe to destroy objects in the reverse
order of their initialization, and it is often necessary to
destroy them in that order.

BTW, you can ensure the correct order of initialization if you do
not access x directly as a static object. For example you could
do this:

 #include "Lock.h"
 Lock& x()
 {
  static Lock the_x;
  return the_x;
 }

Then change uses of "x" to "x()". Now the first use of x will
ensure that the Lock object is already constructed. But you still
need the guarantee of destruction order to write class B.

---
Steve Clamage, stephen.clamage@sun.com

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<tJmQ8.1505$nh.112247972@newssvr14.news.prodigy.com>...
> If you set aside theoretical concerns for a moment, the fact is that on most
> platforms, order of construction IS predictable, even if not specified by
> the standard.  On those platforms, it is possible to construct an executable
> which relies on initialization order of statics.  Such an executable can
> then rely on the guarantee that the standard does provide that the objects
> will be destructed in the reverse of the order in which they were created.
> I would assume that the clause in the standard which mandates that order of
> destruction be the reverse of construction was included in the standard for
> this very reason.

This makes sense, although it seems a little dangerous to rely on
knowledge of the order of construction on a particular platform.
Something along the lines of pragma elaborate would be nice. I suppose
even then it would not be ideal. Forcing the order of initialization
would probably increase the chance of creating mutual dependencies,
just helping to support what was a bad design to begin with. On the
other hand, such a pragma might help by improving diagnostics, giving
a warning or error when some order of initialization could not be
enforced.

Thanks,
    Bob.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message
news:<tJmQ8.1505$nh.112247972@newssvr14.news.prodigy.com>...

> IIRC, having a defined order of initialization was a major work
> effort during standardization, but apparently nothing came of it.
> Perhaps one who was at the meetings could comment?

I don't know if it was a major work effort, but the issue was
certainly discussed.

Since you find the current situation unacceptable, what would you
propose?  IIRC, this was the real problem: what are the alternatives?
In the end, no one could propose a solution which was really useful,
and that could be implemented just about anywhere.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

robert.f.monroe@verizon.net (Robert Monroe) wrote in message
news:<a9f7692.0206190425.65b98fdc@posting.google.com>...
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message
> news:<D5GO8.7488$Nq6.626619602@newssvr13.news.prodigy.com>...
> > "Krzysztof Parzyszek" <kristof@swissmail.org> wrote in message
> > news:ugle1h8haa1jcd@corp.supernews.com...
> > > So, my question is: does the standard mandate that whatever the
> > > order of initialization of all global objects is in a given
> > > case, the order of destruction is guaranteed to be the opposite?

> > Precisely so.

> This is interesting. It is something I was not aware of. I have
> tried to imagine a case where it would be of value to know this rule
> about the order of destruction. I can't think of one. It seems like
> a guarantee based on something that has no guarantee. I know that
> Ada has a few forms of pragma elaborate that address the order of
> initialization. It is easy enough to understand how such a pragma
> would be used.

It can be useful.  If the constructor of a static object is passed a
pointer to an already constructed object, it can save the pointer, and
safely use the object in its destructor.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

robert.f.monroe@verizon.net (Robert Monroe) wrote

> Let me try rewording my question: When would it be significant or
> useful to know the order of destruction when it is based on the
> unknown order of construction? Worded from a different angle, what
> would be the consequence of not having the "destruction in the reverse
> order of construction" guarantee for static objects?

IIRC, the order of construction for objects *within a single
translation unit* is predictable.

    namespace {
        myBuffer   buffer;
        myFile     file("file.dat", buffer);
        myDatabase database(file);
    }

I think you can be sure that buffer will be constructed before file,
and that file will be constructed before database.

In this context, the importance of the guaranteed order of destruction
becomes more obvious. If we destroy the file before we destroy the
database, or if we destroy the buffer before we destroy the file, we
might lose data.

When it comes to guaranteed orders BETWEEN translation units...
well, all I can say is that half the battle is better than none.
(Yes, it is!) Suppose that the three objects above were in
different translation units. We have to build the objects in the
right order -- maybe we find some platform-specific way to do so,
or maybe we rely on sheer dumb luck. Either way, once we pass that
hurdle, we don't have to worry about what happens at program
shutdown -- if they were built in the right order, they'll be
destroyed in the right order too.

(Maybe we create a run-time mechanism that aborts if the objects
are constructed in the wrong order. This mechanism can prevent us
from hitting the main program logic if things weren't built
correctly... such a mechanism can't work on program termination,
because the main program logic would already have finished.)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

[
mods -
  this is a repost.  The first one made it to the moderation queue
  but then fell into a black hole, apparently
- cd
]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0206210410.497fc968@posting.google.com...
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message
> news:<tJmQ8.1505$nh.112247972@newssvr14.news.prodigy.com>...
>
> > IIRC, having a defined order of initialization was a major work
> > effort during standardization, but apparently nothing came of it.
> > Perhaps one who was at the meetings could comment?
>
> I don't know if it was a major work effort, but the issue was
> certainly discussed.
>
> Since you find the current situation unacceptable, what would you
> propose?  IIRC, this was the real problem: what are the alternatives?
> In the end, no one could propose a solution which was really useful,
> and that could be implemented just about anywhere.

Actually, I've rarely had any problem with the current situation.  It's an
annoyance that the standard doesn't define the order of construction, but
since it is predictable for the platforms I'm interested in, I'm content to
use a platform-specific solution where necessary.  In general, I prefer to
avoid designs that rely on order of initialization of statics, instead
making initialization explicit at a slight cost in increased programmer
brain-load in exchange for a portable guarantee of order of creation.

In answer to your question though, I don't have any bright ideas for a
"solution" either.  Such inter-module issues barely fall within the umbrella
of the language definition, given the separate compilation model that's
assumed by C and C++.  In order to specify order of construction of "global"
statics, some notion of a "whole executable" must exist, and that's (to a
large extent) outside the realm of the language spec.  I suppose some sort
of loosely defined sort order could be attached to statics (via a pragma?)
that would at least partially specify the order of initialization without
being onerous for implementors, yet still being useful for users.

My personal preference would be a development environment and program
construction model which abandons the separate compilation model, instead
storing all artifacts of program creation in a database.  Program source
code, parsed code (ASTs), intermediate language code, targeted
(CPU-specific) code, optimized code could all be stored, enabling very
fine-grained dependency analysis, including esoterica like automatically
detecting dependencies (and dependency cycles) between global statics.  I
don't expect that I'll get to use my preferred development environment any
time soon :)

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0206210410.497fc968@posting.google.com...
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message
> news:<tJmQ8.1505$nh.112247972@newssvr14.news.prodigy.com>...
>
> > IIRC, having a defined order of initialization was a major work
> > effort during standardization, but apparently nothing came of it.
> > Perhaps one who was at the meetings could comment?
>
> I don't know if it was a major work effort, but the issue was
> certainly discussed.
>
> Since you find the current situation unacceptable, what would you
> propose?  IIRC, this was the real problem: what are the alternatives?
> In the end, no one could propose a solution which was really useful,
> and that could be implemented just about anywhere.

Actually, I've rarely had any problem with the current situation.  It's an
annoyance that the standard doesn't define the order of construction, but
since it is predictable for the platforms I'm interested in, I'm content to
use a platform-specific solution where necessary.  In general, I prefer to
avoid designs that rely on order of initialization of statics, instead
making initialization explicit at a slight cost in increased programmer
brain-load in exchange for a portable guarantee of order of creation.

In answer to your question though, I don't have any bright ideas for a
"solution" either.  Such inter-module issues barely fall within the umbrella
of the language definition, given the separate compilation model that's
assumed by C and C++.  In order to specify order of construction of "global"
statics, some notion of a "whole executable" must exist, and that's (to a
large extent) outside the realm of the language spec.  I suppose some sort
of loosely defined sort order could be attached to statics (via a pragma?)
that would at least partially specify the order of initialization without
being onerous for implementors, yet still being useful for users.

My personal preference would be a development environment and program
construction model which abandons the separate compilation model, instead
storing all artifacts of program creation in a database.  Program source
code, parsed code (ASTs), intermediate language code, targeted
(CPU-specific) code, optimized code could all be stored, enabling very
fine-grained dependency analysis, including esoterica like automatically
detecting dependencies (and dependency cycles) between global statics.  I
don't expect that I'll get to use my preferred development environment any
time soon :)

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W schrieb:
> (Maybe we create a run-time mechanism that aborts if the objects
> are constructed in the wrong order. This mechanism can prevent us
> from hitting the main program logic if things weren't built
> correctly... such a mechanism can't work on program termination,
> because the main program logic would already have finished.)

but why rely on such an unsure feature anymay?  why not build
software, that is robust with regard to the unspecified
initialization and destruction order between modules?  why not
simply write a class that holds all global data and that does the
initialization and destruction?  or use safe access mechanisms,
such as null initialized pointers and accessor methods?  what is
it worth to use such an unsure language feature, spending lots of
time finding out how it works for your compiler and maybe
spending even more time in searching bugs when something goes
wrong?

regards

 robert

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

allan_W@my-dejanews.com (Allan W) wrote:

>robert.f.monroe@verizon.net (Robert Monroe) wrote
>
>> Let me try rewording my question: When would it be significant or
>> useful to know the order of destruction when it is based on the
>> unknown order of construction? Worded from a different angle, what
>> would be the consequence of not having the "destruction in the reverse
>> order of construction" guarantee for static objects?
>
>IIRC, the order of construction for objects *within a single
>translation unit* is predictable.
>
>    namespace {
>        myBuffer   buffer;
>        myFile     file("file.dat", buffer);
>        myDatabase database(file);
>    }
>
>I think you can be sure that buffer will be constructed before file,
>and that file will be constructed before database.
>
>In this context, the importance of the guaranteed order of destruction
>becomes more obvious. If we destroy the file before we destroy the
>database, or if we destroy the buffer before we destroy the file, we
>might lose data.
>
>When it comes to guaranteed orders BETWEEN translation units...
>well, all I can say is that half the battle is better than none.
>(Yes, it is!) Suppose that the three objects above were in
>different translation units. We have to build the objects in the
>right order -- maybe we find some platform-specific way to do so,
>or maybe we rely on sheer dumb luck. Either way, once we pass that
>hurdle, we don't have to worry about what happens at program
>shutdown -- if they were built in the right order, they'll be
>destroyed in the right order too.
>
>(Maybe we create a run-time mechanism that aborts if the objects
>are constructed in the wrong order. This mechanism can prevent us
>from hitting the main program logic if things weren't built
>correctly

  That's what I do in a similar situation. I assign an arbitrary value
to each of my "linkable" classes as an identifier. If I make a mistake
and assign the same identifier to two of these classes, the
registration function that keeps track of them, which is called by
globally constructed objects and therefore runs before main, aborts.
That prevents me from ever getting to the main program with two
classes that have the same identifier.

>... such a mechanism can't work on program termination,
>because the main program logic would already have finished.)

--
Steve Heller
http://www.steveheller.com
Author of "Learning to Program in C++", "Who's Afraid of C++?", "Who's Afraid of More C++?",
"Optimizing C++", and other books
Free online versions of "Who's Afraid of C++?" and "Optimizing C++" are now available
at http://www.steveheller.com/whos and http://www.steveheller.com/opt

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> Allan W schrieb:
> > (Maybe we create a run-time mechanism that aborts if the objects
> > are constructed in the wrong order. This mechanism can prevent us
> > from hitting the main program logic if things weren't built
> > correctly... such a mechanism can't work on program termination,
> > because the main program logic would already have finished.)

Robert Klemme <bob.news@gmx.net> wrote
> but why rely on such an unsure feature anymay?  why not build
> software, that is robust with regard to the unspecified
> initialization and destruction order between modules?  why not
> simply write a class that holds all global data and that does the
> initialization and destruction?  or use safe access mechanisms,
> such as null initialized pointers and accessor methods?  what is
> it worth to use such an unsure language feature, spending lots of
> time finding out how it works for your compiler and maybe
> spending even more time in searching bugs when something goes
> wrong?

Code reuse, that's why.

You build an object that translates customer numbers into customer
names. It has an internal cache for performance reasons. Your object
relies on a third-party DBMS.

Your DBMS requirements are low, so you've used a client-only DBMS that
is distributed as a C++ library. It uses std::fstreams, which in turn
uses std::new.

This is more than enough to demonstrate the problem. Your global Customer
object needs to access the DBMS during start-up, but has the DBMS been
initialized yet? The DBMS needs to access std::fstreams, but has that
been initialized yet? And so on.

Theoretically, your Customer object could have been written to issue
low-level calls to the operating system: Allocate some memory, open
the DBMS data directly, read the proprietary data format (assuming
you've reverse-engineered it), and load all of the customers into the
cache!

Realistically, the only way to read the DBMS is to ... well, to read the
DBMS. So you have to be sure it's initialized first, and that means that
it has to be sure that everything IT needs is initialized, and so on.

While C++ doesn't provide a mechanism for guaranteeing that the DBMS is
initialized before your global Customer object, but the DBMS could detect
the case where this hasn't happened and report the error. If the DBMS
*is* initialized before your global Customer object, then you don't have
to do the same check during program shut-down: C++ guarantees that your
global Customer object will be destroyed BEFORE the DBMS is, so you can
feel safe to write database modifications from the destructor.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W schrieb:
> Code reuse, that's why.

sorry, i don't understand why this is related to reuse.

> You build an object that translates customer numbers into customer
> names. It has an internal cache for performance reasons. Your object
> relies on a third-party DBMS.
[snip]

i see your point but i'm still not convinced: when using third
party code, you have to take it as it is.  ok.  but third party
code has to cope with the same uncertainties as the code you
write yourself so i use that case for discussion.

i still don't see why you want to rely on automated
initialization when it is unsafe.  i think class variables should
be used carefully and for limited use cases.  a database
initialization is such a complex thing that i would not rely on
static initializations.  taking your example as basis, why don't
you make ThirdPartyDatabase a class like any other of which
instances can be created and destroyed.  the conversion class has
a member of this database class type and creates and destroys it
straightforward.

i just don't see the use of an idiom which is so uncertain and
possibly error prone.  rather than to think of ways to make it
work (rely on platform specific initialization etc.) i opt for
building robust code that simply does not use this feature.

regards

 robert

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<D5GO8.7488$Nq6.626619602@newssvr13.news.prodigy.com>...
> "Krzysztof Parzyszek" <kristof@swissmail.org> wrote in message
> news:ugle1h8haa1jcd@corp.supernews.com...
> > So, my question is:  does the standard mandate that whatever the order
> > of initialization of all global objects is in a given case, the order
> > of destruction is guaranteed to be the opposite?
>
> Precisely so.
> -cd

This is interesting. It is something I was not aware of. I have tried
to imagine a case where it would be of value to know this rule about
the order of destruction. I can't think of one. It seems like a
guarantee based on something that has no guarantee. I know that Ada
has a few forms of pragma elaborate that address the order of
initialization. It is easy enough to understand how such a pragma
would be used.

I would be interested to hear about a use of this guarantee. Possibly
to handle dyanamic memory deallocation? It strikes me as sort of a
lope-sided guarantee.

Bob.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

robert.f.monroe@verizon.net (Robert Monroe) wrote in message news:<a9f7692.0206190425.65b98fdc@posting.google.com>...
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<D5GO8.7488$Nq6.626619602@newssvr13.news.prodigy.com>...
> > "Krzysztof Parzyszek" <kristof@swissmail.org> wrote in message
> > news:ugle1h8haa1jcd@corp.supernews.com...
> > > So, my question is:  does the standard mandate that whatever the order
> > > of initialization of all global objects is in a given case, the order
> > > of destruction is guaranteed to be the opposite?
> >
> > Precisely so.
> > -cd
>
> This is interesting. It is something I was not aware of. I have tried
> to imagine a case where it would be of value to know this rule about
> the order of destruction. I can't think of one. It seems like a
> guarantee based on something that has no guarantee. I know that Ada
> has a few forms of pragma elaborate that address the order of
> initialization. It is easy enough to understand how such a pragma
> would be used.
>
> I would be interested to hear about a use of this guarantee. Possibly
> to handle dyanamic memory deallocation? It strikes me as sort of a
> lope-sided guarantee.

Let me try rewording my question: When would it be significant or
useful to know the order of destruction when it is based on the
unknown order of construction? Worded from a different angle, what
would be the consequence of not having the "destruction in the reverse
order of construction" guarantee for static objects?

    Bob.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Robert Monroe" <robert.f.monroe@verizon.net> wrote in message
news:a9f7692.0206190425.65b98fdc@posting.google.com...

> This is interesting. It is something I was not aware of. I have tried
> to imagine a case where it would be of value to know this rule about
> the order of destruction. I can't think of one. It seems like a
> guarantee based on something that has no guarantee. I know that Ada
> has a few forms of pragma elaborate that address the order of
> initialization. It is easy enough to understand how such a pragma
> would be used.
>
> I would be interested to hear about a use of this guarantee. Possibly
> to handle dyanamic memory deallocation? It strikes me as sort of a
> lope-sided guarantee.

I think you're absolutely right - it's one half of the guarantee that was
really wanted, and is not particularly useful in and of itself.  It's
clearly the correct answer though: destruction should be in the reverse
order of construction.

If you set aside theoretical concerns for a moment, the fact is that on most
platforms, order of construction IS predictable, even if not specified by
the standard.  On those platforms, it is possible to construct an executable
which relies on initialization order of statics.  Such an executable can
then rely on the guarantee that the standard does provide that the objects
will be destructed in the reverse of the order in which they were created.
I would assume that the clause in the standard which mandates that order of
destruction be the reverse of construction was included in the standard for
this very reason.

IIRC, having a defined order of initialization was a major work effort
during standardization, but apparently nothing came of it.  Perhaps one who
was at the meetings could comment?

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Krzysztof Parzyszek" <kristof@swissmail.org> wrote in message
news:ugle1h8haa1jcd@corp.supernews.com...
> So, my question is:  does the standard mandate that whatever the order
> of initialization of all global objects is in a given case, the order
> of destruction is guaranteed to be the opposite?

Precisely so.
-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ugle1h8haa1jcd@corp.supernews.com>, Krzysztof Parzyszek
<kristof@swissmail.org> writes
>For global objects in different translation units their order of ini-
>tialization is not defined.  However, the section 3.6.3 (termination)
>of the standard doesn't seem to restrict itself to a single translation
>unit when it says ``These objects are destroyed in the reverse order
>of the completion of their constructor or of the completion of their
>dynamic initialization.''
>
>So, my question is:  does the standard mandate that whatever the order
>of initialization of all global objects is in a given case, the order
>of destruction is guaranteed to be the opposite?

IIRC, yes. I.e. static objects must register themselves for destruction.


--
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.jamesd.demon.co.uk/csc/faq.html                       ]

For global objects in different translation units their order of ini-
tialization is not defined.  However, the section 3.6.3 (termination)
of the standard doesn't seem to restrict itself to a single translation
unit when it says ``These objects are destroyed in the reverse order
of the completion of their constructor or of the completion of their
dynamic initialization.''

So, my question is:  does the standard mandate that whatever the order
of initialization of all global objects is in a given case, the order
of destruction is guaranteed to be the opposite?


--
<>> kristof@swissmail.org <Krzysztof Parzyszek> |_P
<<> 3,7-Dihydro-1,3,7-trimethyl-1H-purine-2,6-dione

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]