scherrey@proteus-tech.com writes:

>In <3ntn9l$m9n@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

>>What kind of portable code could you write that DOES depend on name
>>mangling but does NOT depend on any other ABI issue? If all you need
>>is a C-like interface, you already have it in C++. Use the linkage
>>specification 'extern "C"' and you are done. If want to write
>>non-C++ code to work portably with a C++ interface, uniform name
>>mangling won't give you the capability. There are too many other
>>platform-specific issues.

>    Here's an example of what I want to do. Say I'm developing a code library or
>DLL for OS/2 using Borland's C++ compiler. I want to release the product as a
>binary DLL with header files that contain the class and method definitions needed
>to link to the DLL. I'm making entire classes and their methods available to be
>called, not just C functions. My understanding is that extern "C" { } wrapped
>around a class definition doesn't work because overloading and the implied this
>argument aren't supported.
>    Now - if someone has the Metaware or Zortech OS/2 compilers, I want them
>to be able to use my product even though its compiled under Borland's OS/2
>compiler. The issue here is that the name mangling differences between the
>various compilers doesn't allow them to resolve the same symbol definitions
>which prevents linkage to my product.

And a darned good thing, too. You evidently didn't bother to read the
other posts on this subject. The primary reason different implementations
choose different name mangling is to prevent linking of incompatible
object files. Things like class layout, implementation of virtual functions,
and function calling conventions are typically quite different among
different compilers. If the program managed to link with an incompatible
DLL, it wouldn't run.

Here's a simple example header file:

 class A {
  ...  // stuff
     public:
  A() { ... } // inline ctor
  int i;  // public data member
  virtual int f(int);
  ...  // more stuff
 };

Compiler X puts the vtable pointer for class A following member i.
Member i is at offset 0 from the start of the class. Arguments
to functions are pushed right to left, with "this" as the leftmost
parameter; "this" is at the top of the stack when the function is
entered.  A function's caller pops the arguments off the stack when
the function returns.

Compiler Y puts the vtable pointer for class A at offset 0 from the
start of the class. Member i is at offset 4. Parameters to functions
are pushed left to right, with "this" as the leftmost parameter;
"this" is at the bottom of the argument portion of the stack. A
function pops its own arguments off the stack as part of returning.

You compile the class and its member functions with compiler X, along
with other code which operates on A objects, and put everything into
a library.

I compile code using the header with compiler Y, and link to your library.

The two portions of code disagree on
- the location of the vtable pointer in a class object
- the location of member 'i' in a class object
- the way in which function arguments are passed (who's on top)
- whether caller or callee adjust the stack after a function call

These object modules cannot work together. I would count myself
lucky if they failed to link because the name mangling was also
different.

You must have a C++ ABI, formal or informal, before code from different
compilers can work together. The C++ ABI will specify name-mangling so
that these compatible compilers will generate code which will link.
It is pointless to specify name mangling apart from an ABI.

A platform ABI is normally sponsored by the OS vendor, especially
if that vendor also supplies compilers. Third-party suppliers can
then choose to follow the ABI for compatibility with other systems,

--
Steve Clamage, stephen.clamage@eng.sun.com

In <3ntn9l$m9n@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

>What kind of portable code could you write that DOES depend on name
>mangling but does NOT depend on any other ABI issue? If all you need
>is a C-like interface, you already have it in C++. Use the linkage
>specification 'extern "C"' and you are done. If want to write
>non-C++ code to work portably with a C++ interface, uniform name
>mangling won't give you the capability. There are too many other
>platform-specific issues.

    Here's an example of what I want to do. Say I'm developing a code library or
DLL for OS/2 using Borland's C++ compiler. I want to release the product as a
binary DLL with header files that contain the class and method definitions needed
to link to the DLL. I'm making entire classes and their methods available to be
called, not just C functions. My understanding is that extern "C" { } wrapped
around a class definition doesn't work because overloading and the implied this
argument aren't supported.
    Now - if someone has the Metaware or Zortech OS/2 compilers, I want them
to be able to use my product even though its compiled under Borland's OS/2
compiler. The issue here is that the name mangling differences between the
various compilers doesn't allow them to resolve the same symbol definitions
which prevents linkage to my product. Instead, I must purchase, and support
the usage of every compiler vendor for OS/2 with my product. Resources much
better used elsewhere.
 That's really all I have to have, other stuff would be nice but this is the
primary objective. Now, if we could add a construct similar to extern "C" {}, say
extern "C++" {}, that would tell the compiler to use the standard mechanism
rather than the proprietary (and possibly more efficient) one, I would be very
happy.

 I hope this makes things more clear. Thanx for your input on this matter.

      Ben Scherrey
      Proteus Technologies, Inc.

In article 4t6@keystone.intergate.net, scherrey@proteus-tech.com writes:
>   I don't doubt your word but I honestly can figure out what
> hardware issues are involved here. Can you give me an example? I think, perhaps
> that the scope that your ABI is taking is larger than what is needed for the goals
> I've stated. It really seems to be to be a naming conventions issue that has to
> take into account some implementation possibilities. I am glad to here that there
> is a work in progress of sorts. Yours is the first hint I've received of any such
> thing.

Others have already answered this so I won't go into much detail.  You could start
by looking at class layout.  You don't WANT the same names if details like that
are different.

> >For example, Sun has a draft of a C++ ABI and we have had a number of meetings
> >with other vendors to get comments and agreements.  We were forced to delay the
> >use of the ABI because the changes introduced in the language by recent ANSI/ISO
> >meetings have forced changes in the ABI, and we insist that this ABI be stable.
> >We will very shortly be starting active work on this again, as the language
> >has become much more stable.
>
>  Would it be possible for me to get hold of a copy of the draft standard.
> I understand that it will me instantly obsoleted but I would like to get details as
> to the scope of the problem it is addressing and what insight has already come
> to light. I do agree that no standard can get far until the language is more stable.
> Also, what does ABI stand for (Application Binary Interface?)?

Yes.  You can send mail to Mukesh.Kapoor@eng.sun.com requesting a copy.

-Mike Ball-

In article rbu@keystone.intergate.net, scherrey@proteus-tech.com writes:
>  This is not, by any stretch of the imagination, a hardware problem. It is
> also not an operating system problem as even compilers running on the exact
> same hardware/OS have different mechanism for name resolution. It is strictly
> a language issue. The problem is that so far the standards committee has dropped
> it off defining it as an implementation detail. While I do agree that it is an
> implementation detail, it desperately needs a standard proposed implementation
> that all vendors would support so code could work between compilers.

Actually, it's an ABI issue.  ABI's are determined by a mixture of hardware
and software issues, and tend to be hard to define.  Anything you define now
is liable to constrain some optimization in the future, and certainly affects
how you add new features.

For example, Sun has a draft of a C++ ABI and we have had a number of meetings
with other vendors to get comments and agreements.  We were forced to delay the
use of the ABI because the changes introduced in the language by recent ANSI/ISO
meetings have forced changes in the ABI, and we insist that this ABI be stable.
We will very shortly be starting active work on this again, as the language
has become much more stable.

This is not something that the ANSI/ISO committee can deal with, as it involves
differences in hardware and software architecture that are far beyond the
committee's control.  For example, many operating systems already have
exception-handling schemes defined, and any C++ scheme must fit into that.
Exception handling is certainly part of any C++ ABI, yet is completely environment-
dependent.

The committee has not abdicated responsibility, it has sensibly decided not to
deal with areas that are beyond its control.  Don't worry, other organizations,
formal and informal, are dealing with the issue.  It's harder than you think,
but it's necessary.  It's also impossible without a stable language on which to
base it.


Mike Ball
SunSoft Developer Products

scherrey@proteus-tech.com writes:

>In <3nr5kp$7oa@engnews2.Eng.Sun.COM>, ball@Eng.Sun.COM (Mike Ball) writes:
>>
>>Actually, it's an ABI issue.  ABI's are determined by a mixture of hardware
>>and software issues, and tend to be hard to define.  Anything you define now
>>is liable to constrain some optimization in the future, and certainly affects
>>how you add new features.


>  I don't doubt your word but I honestly can figure out what
>hardware issues are involved here. Can you give me an example?


Simple example: What is the layout of this struct:

 struct A { char a; double d; };

On some machines, a double must be allocated on an 8-byte address
boundary. On others, a 4-byte boundary is required.  Still others
have no alignment requirement. (Some machines which do not have an
alignment requirement have better performance if you do align objects
appropriately.)

The only universal solution is the one that caters to the worst case.
So your processor with no alignment requirements has to waste up to 7
bytes per double in order to comply with the standard alignment.
And what happens when a machine is introduced which has 16-byte doubles
and requires 16-byte alignment? It will not be able to comply with the
standard layout rules.

I hope you will agree that the C++ language standard cannot specify
layout rules for each machine individually. There would be no way to
keep the list up to date, for one thing, or to find out about all
machines in existence for another.

Such issues must be decided per machine.

But wait -- even that is not enough.

A C++ compiler does not exist in a vacuum. It is part of a larger
system which includes an OS and other language compilers. These systems
often have their own standards. For example, different OS's on the
popular Motorola 680x0 series of computers have incompatible
requirements on data layout and parameter passing.

So the various issues depend not only on the machine, but on the OS.
Per OS, the conventions vary per machine, recognizing hardware
differences. There are macine-specific portions of the Unix SVR4 ABI,
for example. Thus, you need a specification for each machine/OS
combination, or "platform".

>I think, perhaps
>that the scope that your ABI is taking is larger than what is needed for the goals
>I've stated. It really seems to be to be a naming conventions issue that has to
>take into account some implementation possibilities.

If all you want is standard name mangling, I'd have to ask why. If
there is no ABI for a platform, the difference in name mangling is
the least-important difference between two incompatible implementations.
If there is an ABI, the name mangling will be specified in it.

What kind of portable code could you write that DOES depend on name
mangling but does NOT depend on any other ABI issue? If all you need
is a C-like interface, you already have it in C++. Use the linkage
specification 'extern "C"' and you are done. If want to write
non-C++ code to work portably with a C++ interface, uniform name
mangling won't give you the capability. There are too many other
platform-specific issues.
---
Steve Clamage, stephen.clamage@eng.sun.com
--
Steve Clamage, stephen.clamage@eng.sun.com

In <3nr5kp$7oa@engnews2.Eng.Sun.COM>, ball@Eng.Sun.COM (Mike Ball) writes:
>In article rbu@keystone.intergate.net, scherrey@proteus-tech.com writes:
>>  This is not, by any stretch of the imagination, a hardware problem. It is
>> also not an operating system problem as even compilers running on the exact
>> same hardware/OS have different mechanism for name resolution. It is strictly
>> a language issue. The problem is that so far the standards committee has dropped
>> it off defining it as an implementation detail. While I do agree that it is an
>> implementation detail, it desperately needs a standard proposed implementation
>> that all vendors would support so code could work between compilers.
>
>Actually, it's an ABI issue.  ABI's are determined by a mixture of hardware
>and software issues, and tend to be hard to define.  Anything you define now
>is liable to constrain some optimization in the future, and certainly affects
>how you add new features.

 Mike,

  I don't doubt your word but I honestly can figure out what
hardware issues are involved here. Can you give me an example? I think, perhaps
that the scope that your ABI is taking is larger than what is needed for the goals
I've stated. It really seems to be to be a naming conventions issue that has to
take into account some implementation possibilities. I am glad to here that there
is a work in progress of sorts. Yours is the first hint I've received of any such
thing.

>For example, Sun has a draft of a C++ ABI and we have had a number of meetings
>with other vendors to get comments and agreements.  We were forced to delay the
>use of the ABI because the changes introduced in the language by recent ANSI/ISO
>meetings have forced changes in the ABI, and we insist that this ABI be stable.
>We will very shortly be starting active work on this again, as the language
>has become much more stable.

 Would it be possible for me to get hold of a copy of the draft standard.
I understand that it will me instantly obsoleted but I would like to get details as
to the scope of the problem it is addressing and what insight has already come
to light. I do agree that no standard can get far until the language is more stable.
Also, what does ABI stand for (Application Binary Interface?)?

 thanx much & later,

  Ben Scherrey
  Proteus Technologies, Inc.