🚀 go-pugleaf

In article <4fvng1$jit@netlab.cs.rpi.edu>,
Bob Archer  <bob@hottub.demon.co.uk> wrote:
>Singleton * Singleton::Instance() {
>  if (_instance == 0) 
>      _instance = new Singleton;
>  return _instance;
>}
>
>[Jamshid] suggested that using a static local variable might be better:
>
>Singleton * Singleton::Instance() {
>  static Singleton s;
>  return &s;
>}
>
>James Kanze then replied:
>	Although I tend to prefer this idiom too, it is important to realize
>	that there are some cases where it is preferable *not* to destruct the
>	variable.  (If there is only one, this shouldn't constitute a memory
>	leak.)  [...]
>
>Why does the fact that only one variable is involved mean that this is 
>not a memory leak?

James has responded that although technically it is a memory leak,
it's not important unless you're using a poor operating system that
does not recover all memory when a process finishes.  I agree I
wouldn't want to use such an operating system (Win3.1?), but I think
it is sloppy programming to not ensure all the objects you create get
destroyed and all the memory you allocate gets deleted.  Of course
there are probably cases where this is not possible or practical, but
leaked memory and undestroyed objects cause hassles when using
debugging tools like Purify which report all memory leaks when the
program finishes.  You'll get enough leak reports from sloppy 3rd
party libraries -- you shouldn't be adding a bunch "ignore this leak,
I 'know' it's okay" configuration statements for the code you write.
Also, you may sometime soon want to remove the "singleton" restriction
on the class -- IMO get it right the first time and make sure its
destructor works properly.

>I take the point about the Singleton object possibly being used in the 
>destructors of a static object. Is there any way to ensure that the 
>singleton will be destroyed but only after everything that might wish 
>to use it has been destroyed ? (I guess that this is just the usual 
>problem with the order of global construction / destruction ).

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.  At least globals are sensibly guaranteed to be
destroyed in the reverse order they were constructed.  What should
have been required IMO is that local statics be destroyed in the
reverse order they were (fully) constructed.  For example, if the
constructor of a local static "g_list" calls a function containing
another local static "g_log", g_list should be destroyed first since
its construction was finished last.  This is desirable behavior since
g_list's destructor may also use g_log.

With the committee leaving destruction order of local statics
unspecified, you'll have to instead dynamically allocate the singleton
and use atexit() to delete it if you have singletons referring to each
other in their constructor or destructor code.  Note: atexit()
functions are called in the reverse order they were registered.

	class LogFile {
	public:
	   LogFile& theLog() {
	      if (!p) {
	         p = new LogFile;
	         atexit(&destroy);
	      }
	      return *p;
	   }
	private:
	   static LogFile* p;
	   void destroy() { delete p; }
	};

Is there any reason the committee chose not to have local statics do
this kind of ordering automatically?  Of course, it won't solve every
problem related to "global" construction/destruction ordering, but it
seems a lot better than leaving it unspecified and doesn't seem like
it would have placed any burden whatsoever on implementors.

Jamshid Afshar
jamshid@io.com
[ To submit articles: Try just posting with your newsreader.
		      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
]