Path: utzoo!utgpu!watserv1!watmath!watmsg!gjditchfield
From: gjditchfield@watmsg.waterloo.edu (Glen Ditchfield)
Newsgroups: comp.lang.c++
Subject: Re: String class seems unusable in global constructors
Message-ID: <34205@watmath.waterloo.edu>
Date: 13 Feb 90 17:11:13 GMT
References: <1633@aber-cs.UUCP>
Sender: daemon@watmath.waterloo.edu
Reply-To: gjditchfield@watmsg.waterloo.edu (Glen Ditchfield)
Distribution: gnu
Organization: U. of Waterloo, Ontario
Lines: 22

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