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.ukgjditchfield@watmsg.waterloo.edu (Glen Ditchfield) (02/14/90)
In article <THOTH.90Feb11152541@shark.cis.ufl.edu> thoth@shark.cis.ufl.edu (Gilligan) writes: > Is there any way to insure that the Strings package gets initialized > before I try to use them? ... Is such an extension a good idea? In article <1633@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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. Note that Modula-3 has exactly this problem, and solves it. Modula-3 has INTERFACEs (which are like .h files except that IMPORT is not defined as textual inclusion) and MODULEs (which are like .cc files). A module can export more than one interface, and several modules can export disjoint parts of a single interface. There need not be any relationship between the names of interfaces and modules. The kicker is that modules have a block part, and the blocks must be executed in an order that is constrained by the way interfaces are imported and exported. The last block executed is the program's mainline. I think the current Modula-3 compiler has a pre-linker pass that constructs the dependencies, but I haven't looked. In a C++ program, the equivalent of a module's block would execute constructors for global data. The bad news is that there is no equivalent of an EXPORT statement to define .cc file dependencies