Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!news.cs.indiana.edu!rutgers!cbmvax!cbmehq!cbmdeo!lenler!moria!bojsen
From: bojsen@moria.UUCP (Per Bojsen)
Newsgroups: adsp.sw,comp.sys.amiga.programmer
Subject: Major problem with Comeau C++ (and with old Lattice C++), Part 2
Keywords: Comeau C++ 2.1, Lattice C++, static class members, linker preprocessor
Message-ID: <195cf6ce.ARN3855@moria.UUCP>
Date: 26 Jun 91 23:48:14 GMT
Reply-To: cbmehq!moria!bojsen
Followup-To: adsp.sw,comp.sys.amiga.programmer
Organization: IDUN-Soft Aps.
Lines: 81

In part 1 I wrote:

> The solutions:
>
> 1) Create a program that will analyze all object modules of the program,
>    extract all multiply defined objects and place them in a new object
>    module, while removing them from the other object modules.
>
> [...]
>
> Solution (1) is possible but somewhat ugly since object modules may
> have to be changed/patched.
>
I have pondered this solution a bit.  I think it's the easiest of the
four I mentioned in my previous post.  The AmigaDOS object file format
is fairly simple to parse---a lot simpler than parsing C code.

I think there're at least six possible ways to implement (1):

a) Scan the object files for external definitions and put all these in
   a new definition module; remove the definitions from the main object
   files.

b) Like (a) but remove the space allocated for the defined objects
   that are moved to the definitions module.

c) Like (a) but only for external definitions that occur in more than
   one object module.

d) Like (c) but remove the space allocated for the defined objects
   that are moved to the definitions module.

e) Scan the object files for multiply defined external objects; pick
   some occurance (e.g., the first) as the definition and remove the
   others.

f) Like (e) but remove the space allocated for the defined objects
   that are eliminated.

The last two are appealing because no extra object file is needed.  All
methods require that some or all object modules are patched and/or
otherwise changed.  (a) and (b) is the symmetric case.  (b), (d), and
(f) are better than the others because they avoid duplicate allocation
of space.

Should I decide to do the program I will probably implement (f) unless
there's good arguments for implementing some of the others.  Before I
start programmig: does anyone know of a tool like this one?

Note, that this program is a frontend to the linker, and that it could
also be extended to do the magic that the stid program currently does
(i.e., generating the calls to the constructors and destructors of
external class objects).

Ideally, the functionality of this program should be built into blink,
I think.

What does other users of Comeau C++ (and the old Lattice C++) do to
cope with this problem?  Does anyone know if Comeau Computing is working
on the problem?

If I get the time to do the program I'll make it freely distributable,
allowing the C++ vendors to distribute the program with their C++ packages
if they're interested.

--
.------------------------------------------------------------------------------.
|  Greetings from Per Bojsen.                                                  |
+------------------------------+-----------------------------------------------+
|  EMail: cbmehq!lenler!bojsen | "Names do have power, after all, that of      |
|     Or: bojsen@dc.dth.dk     |  conjuring images of places we have not seen" |
`------------------------------+-----------------------------------------------'


--
.------------------------------------------------------------------------------.
|  Greetings from Per Bojsen.                                                  |
+------------------------------+-----------------------------------------------+
|  EMail: cbmehq!lenler!bojsen | "Names do have power, after all, that of      |
|     Or: bojsen@dc.dth.dk     |  conjuring images of places we have not seen" |
`------------------------------+-----------------------------------------------'