In article <3csm5fINNaud@ford.is.wdi.disney.com>, thant@disney.com (Thant Tessman) writes:
|>
|> This problem can be aleviated if an implementation provides a way to
|> translate back and forth between a C++ prototype (which is
|> well-defined) and the name eventually chosen by the compiler (or
|> cfront) for that function.
|>
Most good implementations do this.  One commercial C++ compiler I
know of simply filters the output of the linker and "demangles" the
names as they come out of the linker.  This is perfectly transparent
to the user, and yet is simple to implement, and allows continued use
of the standard linker.

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

In article <3csm5fINNaud@ford.is.wdi.disney.com>,
Thant Tessman <thant@disney.com> wrote:
>
>In article <D0qBoC.6Bx@inter.NL.net>, mcv@inter.NL.net writes:
>
>> [...] If you can write debugging info into your object files, you
>> can write type information into them.  Just add a wrapper around the
>> brain-dead linker, and you're done.  Is that so difficult if you're
>> already building a compiler?
>
>If you want to link different languages to each other, it makes sense
>for the languages to rendesvous closer to the machine's understanding
>of function calls than to any particular language's understanding of
>them.  (A choice between evils, I admit.)  In my case, that rendesvous
>point is "C style linkage."
>
>When trying to hook another language up to C++, I would much prefer
>sticking with standard linker tools and the previously-described
>translator to writing my own C++ savy "wrapper around the brain-dead
>linker".
>
>I've managed to get Chez Scheme and C++ to talk to each other quite
>intimately, and neither my Scheme compiler nor my C++ compiler are
>forced to know about each other.  They just both know about C style
>linkage, and I do the rest.
>
>I would love to hear it if somebody has thoughts on a better way to do
>this kind of thing.  I also wouldn't mind hearing more about what
>exactly Miguel Carrasquer has in mind.
>

I suspect you mean the connection between type-safe linkage and
debugging info, that I hinted at above.  I'm not sure whether this
can be done with every object-file format: it requires that there be
a provision for free-style debug-records in the object file (not
interpreted in any way by the linker).  All the type information
can be stored there, and a "linker preprocessor" could check whether
the imports and the exports of each module match the type-info in the
"debug"-records.  If all's OK, you can invoke the linker, otherwise
an error message is given.  The type-checking can even be done at compile
time when two modules are not mutually dependent on each other.

How does Ada do it?

--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~
mcv@inter.NL.net         ce .sig n'est pas une .cig

In article <D10Jzy.C1M@inter.NL.net> mcv@inter.NL.net (Miguel Carrasquer) writes:
 >                                         All the type information
 > can be stored there, and a "linker preprocessor" could check whether
 > the imports and the exports of each module match the type-info in the
 > "debug"-records.  If all's OK, you can invoke the linker, otherwise
 > an error message is given.  The type-checking can even be done at compile
 > time when two modules are not mutually dependent on each other.
 >
 > How does Ada do it?
 >
In Ada *all* type-checking is done compile time.  The compiler has access
to all information needed to do that.  So, you can not compile a program
that uses a particular external routine (or whatever) until the interface
for that routine has been compiled, nor can you compile the routine itself
in that case.  Moreover, the language requires the compiler to keep track
of such things, so when an interface is changed, the compiler must mark
all compilations using the old interface as obsolete, and require
recompilation (this is a bit simplified of course).

Ada is much more than simply a language.
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl

In article <D0qBoC.6Bx@inter.NL.net>, mcv@inter.NL.net writes:


[...many interesting and good points made...]

> But I haven't yet revealed the real, fundamental and unnegotiable
> reason why I don't like C++:  name mangling.

[...]

> The encoding scheme discussed in the ARM is not standard: every
> vendor can (and does) implement this in their own way.  I thought
> one of the stated objects of C++ was being as compatible as possible
> with C.  Now it's not even compatible with itself.

This problem can be aleviated if an implementation provides a way to
translate back and forth between a C++ prototype (which is
well-defined) and the name eventually chosen by the compiler (or
cfront) for that function.


> [...] If you can write debugging info into your object files, you
> can write type information into them.  Just add a wrapper around the
> brain-dead linker, and you're done.  Is that so difficult if you're
> already building a compiler?

If you want to link different languages to each other, it makes sense
for the languages to rendesvous closer to the machine's understanding
of function calls than to any particular language's understanding of
them.  (A choice between evils, I admit.)  In my case, that rendesvous
point is "C style linkage."

When trying to hook another language up to C++, I would much prefer
sticking with standard linker tools and the previously-described
translator to writing my own C++ savy "wrapper around the brain-dead
linker".

I've managed to get Chez Scheme and C++ to talk to each other quite
intimately, and neither my Scheme compiler nor my C++ compiler are
forced to know about each other.  They just both know about C style
linkage, and I do the rest.

I would love to hear it if somebody has thoughts on a better way to do
this kind of thing.  I also wouldn't mind hearing more about what
exactly Miguel Carrasquer has in mind.

thant