🚀 go-pugleaf

  Has anyone addressed the issue of libraries that depend on globally
constructed data?



  It seems the String class is not usable within global constructors.
I had a class that used Strings extensively and when I had an instance
constructed globally I got a SEGV before main().  I think I tracked
the problem down to the destructor for String.

(gdb) run
Starting program: /cis/lightning0/thoth/grid2/dicttest

Program received signal 11, Segmentation fault
Reading in symbols for AllocRing.cc...done.
0x1e4aa in alloc__9AllocRingi ($this=(AllocRing *) 0x41380, s=10) (AllocRing.cc
line 100)
AllocRing.cc: No such file or directory.
(gdb) where
#0  0x1e4aa in alloc__9AllocRingi ($this=(AllocRing *) 0x41380, s=10) (AllocRing
.cc line 100)
#1  0x17a4e in str__FPCci (...) (...)
#2  0xa5ce in __10dictionaryG6String (...) (...)
#3  0xd794 in _GLOBAL_$I$dict (...) (...)
#4  0x1e2e4 in __do_global_init (...) (...)
#5  0x1e2a6 in __main (...) (...)
#6  0xd39a in main (...) (...)
(gdb) print _nilString
Reading in symbols for String.cc...done.
$1 = {rep = 0x0}				// should be &_nilStrRep
(gdb)

  It looks like the _nilString global object from String.cc is not
initialized yet.  This is most depressing.  Many String functions
misbehave violently if this is not initialized.
  Is there any way to insure that the Strings package gets initialized
before I try to use them?  I haven't read of any way yet.  Is such an
extension a good idea?
  The only alternatives:
 1) Require all library classes to not depend on ANY global
constructed data
 2) document this dependency, so that any classes that use the
afflicted class in their constructors can mention the fact that THEY
can't be globally constructed either.

  I'd also appreciate information on how to demunge the names in my
head.
  Should I cross post to comp.lang.c++?  This seems like an issue for
other people writing libraries in c++.

  THOTH out -=O=-
--
( My name's not really Gilligan, It's Robert Forsman, without an `e' )