Re: RE>C++ linked with other la

[Michael McClary <michael>]

roger: The initialization of static globals is accomplished in C++ by a post
 roger: ld pass that scans the name table of the linked file and generates 
 roger: a initialization routine that it links in.  The problem is that
 roger: users of another language, C for instance, won't have this final phase
 roger: lying around in a convenient way. 

 heh: Apple has solved this problem for the Mac by having the linker build
 heh: a table of all of the static initializers and destructors, and having
 heh: a special function linked in (from the c++ library) that calls all of
 heh: them at the right time.

Cute.  I can think of a couple other ways to do it:

An initializer module might also be written by a formic-like preprocessor
passed over the source code, or (when the environment allows it) by a
utility that uses the namelists from the object, rather than the linked,
files.

Smalltalk might be persuaded to write an initializer (or set of them)
for the code it outputs.  This could be combined with a hand-written
one for the hand-written code.

Smalltalk, formic, or whatever could just generate a file of initializer
table entries for each moudule, and these could be cat-ted together to
form a composite file to be #include-d in the actual initializer
subroutine.

The reason for generating an initializer module by running a
bogus_link -> name-extract -> module_generate -> real_link is to sort
out the static initializers extracted from C++ object libraries.
Running the module-generator only on the objects would miss library
initializers, while running a dumb one over both the objects and the
libraries would produce an initialization module that would suck in
the whole library.

Since we're sucking in our whole library anyhow, we can get away with
even brain-damaged approaches until shortly before shrinkwrap.

 heh: Now... if they could only get the linker to work...

I second that.

	michael