thoth@shark.cis.ufl.edu (Gilligan) (02/12/90)
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' )pcg@aber-cs.UUCP (Piercarlo Grandi) (02/13/90)
In article <THOTH.90Feb11152541@shark.cis.ufl.edu> thoth@shark.cis.ufl.edu (Gilligan) writes:
Has anyone addressed the issue of libraries that depend on globally
constructed data?
Yes, and ...
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.
There is no way. The only guaranteed order of construction is
within a source file. You cannot depend on global constructors
in other files.
Is such an extension a good idea?
No, because it would require a quite smart linker, which could
be done, and it would require looking at a C++ program as a
whole, even if broken in lots of little pieces. So far, this is
not the case. Each C/C++ source file is fully independent (note
that #include *replicates* code in all the source files).
The only alternatives:
1) Require all library classes to not depend on ANY global
constructed data
Oh yes.
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.
Oh no.
The third alternative is not to use globally constructed
objects at all. Initialize everything in your 'main' explicitly.
It is a bit backwards...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk