In article <3gmdcp$pp1@hermes.synopsys.com> jbuck@synopsys.com (Joe
Buck) writes:

|> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

|> >I don't think it is that bad, since you can use extern "C" to avoid
|> >name mangling if you need to.

|> We can't weasel out of it that easily, Fergus.  Class libraries can't
|> use extern "C" for all their interfaces, as they are then no longer
|> class libraries but just plain old C libraries.  The result is that
|> the whole application must be compiled with the exact same C++ compiler,
|> which means that if any of it is shipped in object form, then this
|> constrains what compiler the user can use.

|> Of course it's possible for parts of the library to be shipped in object
|> form: to be portable, everything shipped across the boundary of this
|> object code has to be a Plain Old Data Structure, an extern "C" function
|> interface, or an opaque pointer.  This can be OO in the sense that the X
|> intrinsics are OO (object-oriented programming in C with pointers to an
|> undefined struct type).

Even this isn't enough for all machines.  Padding may differ within a
struct, for example.

The standard only addresses the case where the library and the
application are compiled with the same compiler, same version, and
using the same compiler flags, and when the vendor makes the claim
that these flags result in a standards conforming implementation.

Most vendors do try to be a little bit more flexible.  But if you've
ever tried to link a library compiled in SMALL with an application
compiled in LARGE under DOS, you'll realize that even having
everything compiled with the same compiler, on the same machine, is no
guarantee.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3gmdcp$pp1@hermes.synopsys.com> jbuck@synopsys.com (Joe Buck) writes:
> ...
>Specifying standard per-platform binary interfaces is beyond the scope
>of the ANSI/ISO committee.  This doesn't mean that it wouldn't be very
>valuable to do *after* the working paper has become an essentially
>complete draft standard.

I'm not sure that developing object layout standards for each platform is
really necessary.  Specifying these things as implementation-defined behavior
would seem to be what's required.  How does the ANSI C specification handle
this?  I know I can determine the physical memory layout of a C struct given
the compiler documentation for all of the compilers I've dealt with.

 Paul J. Ste. Marie,
 pstemari@well.sf.ca.us, pstemari@erinet.com

Doug Judd <djudd@ads.com> writes:
>>Why doesn't the C++ standard specify an intermediate symbol name
>>format?

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>There are a whole lot of good reasons.  See the gnu.g++.help FAQ list
>for some of them.

Yes, as I write in the g++ FAQ (I'm the author), incompatible mangling is
needed to protect users from incompatible object layout and virtual
function implementation.  Given this, the more relevant question would be
"Why doesn't the C++ standard mandate somehow that conforming code
compiled by different conforming C++ compilers on the same platform will
link and run successfully?"  (Short answer: too early, what is a
"platform", ...).

>>This seems like a major drawback, especially for library
>>vendors.

>I don't think it is that bad, since you can use extern "C" to avoid
>name mangling if you need to.

We can't weasel out of it that easily, Fergus.  Class libraries can't
use extern "C" for all their interfaces, as they are then no longer
class libraries but just plain old C libraries.  The result is that
the whole application must be compiled with the exact same C++ compiler,
which means that if any of it is shipped in object form, then this
constrains what compiler the user can use.

Of course it's possible for parts of the library to be shipped in object
form: to be portable, everything shipped across the boundary of this
object code has to be a Plain Old Data Structure, an extern "C" function
interface, or an opaque pointer.  This can be OO in the sense that the X
intrinsics are OO (object-oriented programming in C with pointers to an
undefined struct type).

Specifying standard per-platform binary interfaces is beyond the scope
of the ANSI/ISO committee.  This doesn't mean that it wouldn't be very
valuable to do *after* the working paper has become an essentially
complete draft standard.



--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

Doug Judd <djudd@ads.com> writes:
>Why doesn't the C++ standard specify an intermediate symbol name
>format?  This seems like a major drawback, especially for library
>vendors.

See the comp.lang.c++ and gnu.g++.help FAQs.  In short, consistent names
is the least of the problems: different compilers lay out objects, virtual
function tables, etc, differently.  Since Microsoft has patented their
layout for objects with virtual base classes or multiple inheritance, it
appears other vendors can't be compatible with them without infringing
the patent.  (I think the patent in question is bogus, but this could be
an expensive proposition to establish in a court of law).

(Microsoft started with the "thunks" implementation style described in the
ARM for more compact virtual function tables for multiple inheritance,
made a simple improvement and patented that).

If a standard name mangling rule were specified, applications would link,
but then crash when run.  Therefore the ARM *encourages* vendors of
non-compatible implementations to use incompatible name mangling formats.




--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

Doug Judd <djudd@ads.com> writes:

>Why doesn't the C++ standard specify an intermediate symbol name
>format?

There are a whole lot of good reasons.  See the gnu.g++.help FAQ list
for some of them.

>This seems like a major drawback, especially for library
>vendors.

I don't think it is that bad, since you can use extern "C" to avoid
name mangling if you need to.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
>
> d94215@rix01.lyngbyes.dk (Martin L   bger) writes:
>
> >I have a HUGE (not tiny, small, medium, compact or large ;-) problem.
> >I can't find out how to write a function in assembler, compile it to a
> >.OBJ file, and then use it in my c++ program. Can anyone please help my
> >with this problem.
>
> The C++ standard does not specify any portable way of doing this.
>
> --
> Fergus Henderson - fjh@munta.cs.mu.oz.au
> all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)

Why doesn't the C++ standard specify an intermediate symbol name
format?  This seems like a major drawback, especially for library
vendors.

- Doug

 o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
 Doug Judd
 Advanced Decision Systems (Booz-Allen & Hamilton, Inc.)
 1500 Plymouth St., Mountain View, CA 94043-1230
 djudd@ads.com, (415) 960-7450

d94215@rix01.lyngbyes.dk (Martin L   bger) writes:

>I have a HUGE (not tiny, small, medium, compact or large ;-) problem.
>I can't find out how to write a function in assembler, compile it to a
>.OBJ file, and then use it in my c++ program. Can anyone please help my
>with this problem.

The C++ standard does not specify any portable way of doing this.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au
all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-)