Path: utzoo!mnetor!uunet!husc6!hao!gatech!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: c++ for vms
Message-ID: <10016@ulysses.homer.nj.att.com>
Date: 6 Feb 88 21:47:33 GMT
References: <303@nih-csl.UUCP> <4800013@uiucdcsm> <6079@tut.cis.ohio-state.edu>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Lines: 39

In article <6079@tut.cis.ohio-state.edu> thomas@tut.cis.ohio-state.edu (Steven Thomas) writes:
>
>We recently (last week) purchased c++ for our vms system from Oasys in
>Cambridge, MA.  In our initial review we've found that the Oasys system patches
>the executable after c++ preprocessor, the c compiler and the linker have all
>run.  We called them and asked why it was necessary to patch the executable,
>and they stated that the implementation of constructors and destructors require
>this patch.  We still remain unconvinced.  So several questions arise ...
>

I'm not sure what you are concerned about.  All cfront based C++
compilers that I am aware of either do a patch after the link step or
do the  link step twice.

>1)  Can anyone explain why the executable image should need to be patched after
>	creation by the linker?

Oasys' explanation is correct.  A top level (file scope) declaration
of an object with a constructor requires the constructor to be called
at program start up.  Cfront arranges for source files containing
such declarations to also contain a function, with a distinctive
name, that calls the constructors.  The patching is arranging for the
initialization code to locate all these socalled STI functions.
Finding all the STI functions must be done after linking to cover the
cases where STI functions occur in object files brought in from
libraries.

Jerry Schwarz
Bell Labs

P.S.  I raise my usual objection to referring to the cfront phase of
C++ compilers as a preprocessor step.  I haven't stated in this
newsgroup in a few months, so for those who haven't seen it before:

Cfront is not a preprocessor because if there is an error message
during the compilation of the generated C, we know without further
investigation that it is a bug in cfront, in the C compiler or in the
way they are put together.  It is completely analogous to an message
from the assembler during an ordinary C compilation.