In article <4q72pq$2c2@ns.hcsc.com> bill@amber.ssd.hcsc.com (Bill
Leonard) writes:

|> Given the rather weak requirements placed on static construction (and thus
|> destruction) of objects declared at file scope, it would be more consistent
|> if the standard merely said that local static objects were destroyed
|> "sometime after the last call to the function containing them".  That would
|> leave the implementation free to destroy such objects when a
|> dynamically-linked library was unloaded, since the implementation knows at
|> that point that any functions in that library will no longer be callable.

Yikes.  The generally accepted idiom for singletons (I believe) is to
have a function return a pointer to a local object.  Are you saying
that you want this object to be able to disappear at some unspecified
time, before program end.  (I know enough to not try and use such
objects in static destructors.)

In the case of DLL's, I also know enough not to put such functions in
DLL's which may be unloaded before program end.  But, IMHO, the
standard does not, and should not (at least this time around) consider
DLL's; anything to do with DLL's is a vendor supplied extension, and I
have to program to the vendors specs, and not the standard, when using
them.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I have a question about the order of destruction of local static variables.
Can a program rely on the order of destruction of local statics that are
declared in different functions?  For example:


   class A {
   public:
      A(int a);
      ~A();
   };

   void
   f() {
      static A x(1);

      // do something with x.
   }

   void
   g() {
      static A y(2);

      f();
   }

   void
   main() {
      g();
   }


In this program, I know that "y" will be constructed before "x".  But can I
rely on variable "x" being destroyed before "y"?  If the answer is yes,
does it make any difference whether "f" and "g" are in the same compilation
unit or not?

A related question is the relationship between the destruction of "x" and
"y" and the execution of any atexit functions.  The April WP says:

   "The destructor [for a local object with static storage duration]
    is called either immediately before or as part of the calls of the
    atexit() functions.  Exactly when is unspecified." (6.7.5)

and

   "Destructors for initialized static objects are called when
    returning from main() and when calling exit().  Destruction is
    done in reverse order of initialization.  The function atexit()
    from <cstdlib> can be used to specify a function to be called at
    exit.  If atexit() is to be called, the implementation shall not
    destroy objects initialized before an atexit() call until after
    the function specified in the atexit() call has been called." (3.6.3.1)

Is it permissible to destroy *all* the local static objects *after* calling
all the atexit functions (but before doing anything else required of the
implementation at exit)?  Or is this saying that the implementation must
interleave object destruction and atexit functions?

On the one hand, the WP seems to be going out of its way to avoid exactly
specifying when the objects are destroyed, but then it makes requirements
related to atexit that (perhaps) restrict the choices.  Or am I reading too
much into this?

Thanks in advance.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

bill@amber.ssd.hcsc.com (Bill Leonard) writes:

>I have a question about the order of destruction of local static variables.
>Can a program rely on the order of destruction of local statics that are
>declared in different functions?

The current draft says they are destroyed in reverse order of their
construction. It doesn't matter whether they are in different
translation units.

>A related question is the relationship between the destruction of "x" and
>"y" and the execution of any atexit functions.  The April WP says: ...

Here is what the current draft says, and I think it answers your
questions:

3.6.3 Termination [basic.start.term]

1: Destructors (12.4) for initialized objects of static storage duration
(declared at block scope or at namespace scope) are called when returning
from main and when calling exit (18.3). These objects are destroyed in the
reverse order of the completion of their constructors. For an object of
array or class type, all subobjects of that object are destroyed before
any local object with static storage duration initialized during the
construction of the subobjects is destroyed.

2: If a function contains a local object of static storage duration that
has been destroyed and the function is called during the destruction of
an object with static storage duration, the program has undefined behavior
if the flow of control passes through the definition of the previously
destroyed local object.

3: If a function is registered with atexit (see <cstdlib>, 18.3) then
following the call to exit, any objects with static storage duration
initialized prior to the registration of that function will not be
destroyed until the registered function is called from the termination
process and has completed. For an object with static storage duration
constructed after a function is registered with atexit, then following
the call to exit, the registered function is not called until the
execution of the object's destructor has completed.

4: Where a C + + implementation coexists with a C implementation, any
actions specified by the C implementation to take place after the atexit
functions have been called take place after all destructors have been called.

5: Calling the function
 void abort();
declared in <cstdlib> terminates the program without executing destructors
for objects of automatic or static storage duration and without calling
the functions passed to atexit())

--
Steve Clamage, stephen.clamage@eng.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4q1al7$i87@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM
(Steve Clamage) writes:

> Here is what the current draft says, and I think it answers your
> questions:

[quote elided]

Well, it sort of answers my question, but it raises some others.  Here is
what I think this means:

  * A good way to arrange for the destruction of local statics is to use
    "atexit" (but see below).

  * If you *don't* use atexit to arrange for destruction, whatever you
    use had better work exactly as though you had.

Now here's the problem: The C standard (and, by inclusion, the C++
standard) only guarantees that you can register 32 functions with atexit.
So how can a C++ implementation, particularly one based on a C
implementation, use atexit for local static destruction without intruding
on this limit?

Does X3J16 have some alternative implementation scheme in mind?

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>  * If you *don't* use atexit to arrange for destruction, whatever you
>    use had better work exactly as though you had.

And what if the first time a local static object is constructed is during
atexit() processing?. (I could easily register a C++ function that contains
local static objects with atexit() and never call it to make this happen).

(The big problem with being a programmer is thinking of things like this :-).
--
--
Tom.Horsley@mail.hcsc.com  or  Tom.Horsley@worldnet.att.net
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL  33309
The 2 most important political web sites: http://www.vote-smart.org (Project
Vote Smart), and http://ourworld.compuserve.com/homepages/TomHorsley (Me!)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4q1al7$i87@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM
(Steve Clamage) writes:

> Here is what the current draft says, and I think it answers your
> questions:

[quote elided]

Another question this raises concerns implementations that provide
dynamically-linked libraries.  Some such implementations allow libraries to
be loaded and unloaded during execution of the program.  The standard seems
to preclude such a library from containing a C++ function with a local
static object, because it would have to destroy the local object after the
library has ceased to be a part of the program.

I fully realize that the standard does not (and cannot) talk about things
like dynamically-linked libraries.  However, it should not preclude their
existence nor drastically limit their capability.

Given the rather weak requirements placed on static construction (and thus
destruction) of objects declared at file scope, it would be more consistent
if the standard merely said that local static objects were destroyed
"sometime after the last call to the function containing them".  That would
leave the implementation free to destroy such objects when a
dynamically-linked library was unloaded, since the implementation knows at
that point that any functions in that library will no longer be callable.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
There's something wrong with an industry in which amazement is a common
reaction to things going right.

"Hard work never scared me.  Oh, sure, it has startled me from a distance."
                                                       -- Professor Fishhawk
------------------------------------------------------------------------------
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]