Adam (kalessin@netcom.com) wrote:

> I do agree, though, that name mangling should be standardized, as well
> as whatever else is needed to allow OBJ's from different compilers to link

  If men could learn from history, what lessons it might teach us!  But
  passion and party blind our eyes, and the light which experience gives
  is a lantern on the stern, which shines only on the waves behind us!

It's hard to follow Coleridge, but...

The "whatever else" is the HARD part, and is the part least likely to be
resolved any time soon: it would require all the vendors to bury their
disagreements about calling conventions (and each different one really is
best, depending on your assumptions, but I'll refrain from quoting
Kipling just now), the exact names and semantics for all the compiler
helper functions, the handling of template instantiation (that's one that
no one has really worked out yet)... and so on.  The different name
mangling schemes were recommended, if not caused by, the considered
advice that different compilers' objects NOT fit together (in the eyes of
the linker, which traditionally sees only those external names) exactly
to prevent accidental mixing of compiler outputs that couldn't possibly
execute correctly...

Someday this may be a reasonable goal: for now, it's not even close on
platforms lucky enought to have multiple vendors producing competing C++
compilers.  Name mangling is the trivial part of binary compatability!

In <kalessinD7o0Dq.EyM@netcom.com>, kalessin@netcom.com (Adam) writes:
>>Actually, SOM is implemented in C and uses C bindings. The Direct To SOM
>>stuff is neat and works well but does impose a little bit of overhead. The
>>overhead is ok usually but the biggest problem is the fact that SOM isn't a platform
>>independent solution.
>There is SOM for windows, and SOM is planned for other platforms (some of
>the UNIX variants, I think). SOM is not a proprietary OS/2-only thing.
>I do agree, though, that name mangling should be standardized, as well
>as whatever else is needed to allow OBJ's from different compilers to link
>smoothly.
>

I don't think this last point is at all practical.  Picture what needs
to be standardised to allow two different vendors C++ compilers to mix
OBJ files in the same linkage:
 1.  Generate *exactly* the same (C++) object layout for a given
     class declaration;
 2.  Use the same virtual function dispatching mechanism.
 3.  Use exactly the same function calling conventions, including
     register use.
 4.  Use the same run-time library, including all the internal
     functions used to support C++ language mechansisms, such
     as, for example, delete[] or throw/catch.

This would involve a fantasticly detailed standard, that would have to be
re-written for every platform (and OS?).  Name mangling is the least of your
problems in you want to mix OBJs from different compilers.

-Ron

In <3nl94p$liv@silver.jba.co.uk>, JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:
>scherrey@proteus-tech.com wrote:
>: In <D7FK9G.6HF@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>: >In article <3n9i59$c1p@keystone.intergate.net>,
>
>: >> Secondly, can someone address what has been done (if anything) about
>: >>normalizing some kind of standard for performing name mangling?  [...]
>: >>The extern "C" stuff don't cut it because I want objects, not simple
>: >>functions shipped in my libs.
>: >
>: > You may interested in various industry standards such as
>: >IBM's SOM, Suns OBI, OMG's CORBA, Microsoft DLLs or OLE standards,
>: >etc: the ANSI/ISO C++ committee deliberately will not address
>: >these issues directly.
>:
>:      Unfortunately, every one of those systems you describe are implemented
>: using old-C bindings, not C++.

>Wrong.  SOM use, for one, is used *directly* from the C++ language
>if you use a DirectToSOM C++ compiler.
>
>I should know.  I have two of them.
>
>And, before you ask, *YES* I can write a C++ class in MetaWare High C++
>using DirectToSOM C++, link it into a DLL, and use it from an application
>written in IBM CSet++.  It does work.  I've done it.
>
>Of course, with SOM, name mangling is not an issue unless you use name
>lookup resolution anyway.  Most people tend to use offset resolution, and
>the point is moot.  You don't even have the hassle of writing zillions of
>mangled names into the DEF file, either.

 Actually, SOM is implemented in C and uses C bindings. The Direct To SOM
stuff is neat and works well but does impose a little bit of overhead. The
overhead is ok usually but the biggest problem is the fact that SOM isn't a platform
independent solution. The whole point is we write code that compiles and
executes without any changes on multiple OS platforms. This really is a problem
that needs to be addressed as a C++ standards issue, IMHO.

 thanx & later,

  Ben Scherrey
  Proteus Technologies, Inc.

>Actually, SOM is implemented in C and uses C bindings. The Direct To SOM
>stuff is neat and works well but does impose a little bit of overhead. The
>overhead is ok usually but the biggest problem is the fact that SOM isn't a platform
>independent solution.
There is SOM for windows, and SOM is planned for other platforms (some of
the UNIX variants, I think). SOM is not a proprietary OS/2-only thing.
I do agree, though, that name mangling should be standardized, as well
as whatever else is needed to allow OBJ's from different compilers to link
smoothly.

---
Adam Megacz - kalessin@netcom.com
WebPage: ftp://ftp.netcom.com/pub/ka/kalessin/adam.html
TEAM OS/2 MEMBER! Why Snooze with MicroSloth WinDoze? GET WARPED!

scherrey@proteus-tech.com wrote:
: In <D7FK9G.6HF@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
: >In article <3n9i59$c1p@keystone.intergate.net>,

: >> Secondly, can someone address what has been done (if anything) about
: >>normalizing some kind of standard for performing name mangling?  [...]
: >>The extern "C" stuff don't cut it because I want objects, not simple
: >>functions shipped in my libs.
: >
: > You may interested in various industry standards such as
: >IBM's SOM, Suns OBI, OMG's CORBA, Microsoft DLLs or OLE standards,
: >etc: the ANSI/ISO C++ committee deliberately will not address
: >these issues directly.
:
:      Unfortunately, every one of those systems you describe are implemented
: using old-C bindings, not C++.

Wrong.  SOM use, for one, is used *directly* from the C++ language
if you use a DirectToSOM C++ compiler.

I should know.  I have two of them.

And, before you ask, *YES* I can write a C++ class in MetaWare High C++
using DirectToSOM C++, link it into a DLL, and use it from an application
written in IBM CSet++.  It does work.  I've done it.

Of course, with SOM, name mangling is not an issue unless you use name
lookup resolution anyway.  Most people tend to use offset resolution, and
the point is moot.  You don't even have the hassle of writing zillions of
mangled names into the DEF file, either.