Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!oliveb!pyramid!prls!philabs!linus!mbunix!nsds
From: nsds@mbunix.mitre.org (Neil S. Smith)
Newsgroups: comp.lang.c++
Subject: Re: C++ --> C
Message-ID: <50732@linus.UUCP>
Date: 19 Apr 89 16:31:47 GMT
References: <173@cs.columbia.edu>
Sender: news@linus.UUCP
Reply-To: nsds@mbunix (Neil Smith)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 25

In article <173@cs.columbia.edu> jordan@cs.columbia.edu (Jordan Hayes) writes:
>Say you don't have a C++ compiler for a certain kind of machine,
>but you do have a C compiler.
>Can you get g++ or cfront to generate C on the Sun and have the
>unnamed machine compile that?

Even if cfront does generate C-compilable code, and the code is
compiled and linked on the target machine, there is still the problem
of static object constructors and destructors.  The AT&T system (and
most systems derived from it, I imagine), injects calls to the
constructors and destructors of static objects into either the linked
executable or the object files (before linking), depending on the
system used.  This is the 'munch' phase of translation.

It seems to me insufficient simply to turn C++ into C via cfront and
compile the C code on the target machine, without also providing for
the inclusion of calls to static object constructors and destructors.

				neil smith
				(nsds@mitre.org)

---------------------
Neil Smith                              "Relax, don't worry, have a homebrew!"
The MITRE Corporation   M/S B310    Burlington Road         Bedford, MA  01730
Ma Bell:  (617) 271-8278                             Internet:  nsds@mitre.org