🚀 go-pugleaf

In article <9602261828.AA28873@lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763  <kanze@lts.sel.alcatel.de> wrote:
>In article <4go9au$l8f@engnews1.Eng.Sun.COM> Jamshid Afshar
><jamshid@IO.COM> writes:
>
>1. As long as there is an active pointer to the memory (a static
>pointer), Purify will not classify it as a leak.

You're right.  I thought there was some kind of report of all unfreed
memory at program exit.

>In general, I would stress that the prefered solution is to not use
>the singleton object in any destructors, and use a local static to
>initialize the pointer.  If you do have to use the object in
>destructors, however, I would still prefer not destructing it to
>trying to manage the `order of destruction' problem (given that most
>compiler implementors still consider the order of destruction of
>static locals undefined).

I agree I would rather have the compiler manage the destruction,
especially since it's so easy for them to do it (just generate a
"destroy" function and register it with atexit() when the constructor
returns).

>|> Actually, the construction and destruction of "local objects of static
>|> storage duration" is not the same as objects outside of functions.  In
>|> fact, it seems local statics are more poorly specified.  According to
>|> the April '95 Draft, while they are guaranteed to not be constructed
>|> until (and if) the function is called, exactly when the destructor is
>|> called is unspecified.
>
>I actually believe that it is, and in fact, has been well defined from
>the ARM.

Okay, I see now that I was misreading section 6.7 Declaration
Statement in the ARM and April 95 Draft.  I took the sentence "Exactly
when is unspecified" to mean the destructor order is *completely*
unspecified.  I guess the sentence is only referring to the previous
sentence (ie, "Whether the destructor is called before or as part of
the atexit() functions is unspecified.").

   5 The destructor for a local object with static storage duration will be
     executed if and only if the variable was constructed.  The  destructor
     is  called  either  immediately  before or as part of the calls of the
     atexit()  functions  (_lib.support.start.term_).   Exactly   when   is
     unspecified.

>In any case, the Jan. 96 draft makes the question moot, since it
>explicitly adds the words in the destructor section clarifying that
>static means both local and non-local.

I assume you're referring to 3.6.3 Termination (analogous to ARM 3.4
Start and Termination).  Btw, has the wording in 6.7 been changed or
improved?  There seems to be some conflict with it and 3.6.3 wrt the
order of static destructors and atexit() calls.

>|> [...] What should
>|> have been required IMO is that local statics be destroyed in the
>|> reverse order they were (fully) constructed. 
>
>I agree.  The remaining weak point in the standard is that it doesn't
>really specify what is meant by the ordering, entering the
>constructor, or leaving it.

If the Standard does not require local statics to be destroyed in the
reverse order they were *fully* constructed, local statics are useless
to the many programmers who have singletons that use another singleton
during its construction and destruction (eg, all singletons may report
their construction and destruction to a "logfile" singleton).
Programmers will instead have to dynamically create the singletons and
either never delete them or use the "atexit(&destroy)" technique I
mentioned.  The "atexit(&destroy)" technique isn't difficult (you can
even wrap it up in a template), but it seems silly for this to be 1)
unspecified and 2) specified in a manner that makes local statics so
much less useful.

Jamshid Afshar
jamshid@io.com
---
[ 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 
]