Re: Bugs/non-portable assumptions in libstdc++

["Dale E. Martin" <dale at the-martins dot org>]

> Order of static initialization issues are more of an issue,
> portability-wise*. In general, because of this, we are moving to
> returning references to static locals. See the __mt_alloc design.

Another issue I _think_ I've seen in the past is where certain OSes don't
do static initialization the way you might expect when you "dlopen" a C++
shared library.  Iirc, the problem I have seen is that static initializers
don't get called at all in this kind of code in global scope:
static foo *static_foo = new foo();

(I believe Solaris was the culprit on this one, and it's probably been a
few years so maybe it's a non-issue now.)

I've resorted to the idiom you mention for these cases:
const foo &
get_static_foo(){
  static foo *retval = new foo;
  return *retval;
}

Destruction of this object is another issue of course.  I have no idea if
there is any expectation one should be able to dlopen libstdc++ or not :-)

Take care,
     Dale
-- 
Dale E. Martin - dale@the-martins.org
http://the-martins.org/~dmartin