In article <1992Mar31.193816.23051@borland.com> pete@borland.com (Pete Becker) writes:

*His explanation* for some of the design decisions of the Microsoft compiler.

Which is at best speculative on his part.

A thousand pardons if this is a much-rehashed subject...If so,
illuminate me by e-mail and I'll shut up.

According to a number of sources, there is no "standard" on how a
C++ compiler should mangle names. So, if you compile module X with
compiler A and module Y with compiler B, there is no guarantee that
you can link the two objects. This appears to defeat the whole purpose
of pre-compiled commercial class libraries, unless you're willing to
buy a copy of every bleeding C++ compiler available, or the library
vendors are willing to distribute copies compiled with every bleeding
C++ compiler (assuming they're allergic to distributing sources).

G++ evidently won't work with cfront code (I'm told). How many other
C++ compilers suffer from this problem? Why isn't this a standard?
Seems to me to be far too important a problem to be left to the whims
of the compiler writers. Do most simply do what cfront does? Any good
reason why they shouldn't?

Annoyed,
--

james montebello (uunet!racerx!james)         'my employer has no opinions'
Be regular and orderly in your life like a bourgeois, so that you may be
violent and original in your work. -Flaubert

Name mangling standardization wouldn't help unless you also standardized
lots of other things:

   * Implementation of MI

   * Implementation of virtual functions

   * Implementation of static constructors

   * Layout of class members

   * Names and calling conventions for library support routines (whatever
     implements 'new', etc).

That's all I can think of off the top of my head, but soon we will have:

   * Implementation of exceptions

   * Maybe implementation of templates (I don't know if this is an object
     file format issue or not).

The list will only keep getting bigger. The correct way to standardize class
libraries is to ship source, but even that doesn't help much because at the
moment, even something as simple as a set of known header files isn't even
very standard (presumably the C++ standard will at least fix that for most
OS independent things, and maybe someday we will have a POSIX C++ binding
for other more OS dependent stuff, but who knows).
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+

In article 1057@racerx.UUCP, james@racerx.UUCP (James Montebello) writes:
>According to a number of sources, there is no "standard" on how a
>C++ compiler should mangle names. So, if you compile module X with
>compiler A and module Y with compiler B, there is no guarantee that
>you can link the two objects. This appears to defeat the whole purpose
>of pre-compiled commercial class libraries, unless you're willing to
>buy a copy of every bleeding C++ compiler available, or the library
>vendors are willing to distribute copies compiled with every bleeding
>C++ compiler (assuming they're allergic to distributing sources).

One obvious reason is that in an ideal world, object file formats should
contain the type information necessary for a linker to check argument
types at link time without a need for encoding them into function names.
If you had a smart object-file format like this (I believe that SVr4 ELF and
the OSF object format can store type information) you wouldn't want to
force it to use the name-mangling kludge that is used to get type information
into object file formats that do not support it (eg. BSD and COFF).


==============================================================================
Chris Flatters    |  cflatter@nrao.edu
National Radio Astronomy Observatory |
==============================================================================
Desperation is the raw material of drastic change --- W. S. Burroughs
==============================================================================

In comp.std.c++, james@racerx.UUCP (James Montebello) writes:

> A thousand pardons if this is a much-rehashed subject...If so,
> illuminate me by e-mail and I'll shut up.

> According to a number of sources, there is no "standard" on how a
> C++ compiler should mangle names. So, if you compile module X with
> compiler A and module Y with compiler B, there is no guarantee that
> you can link the two objects. This appears to defeat the whole purpose
> of pre-compiled commercial class libraries, unless you're willing to
> buy a copy of every bleeding C++ compiler available, or the library
> vendors are willing to distribute copies compiled with every bleeding
> C++ compiler (assuming they're allergic to distributing sources).

Not at all.

There is no standard that says how a C compiler should do storage
allocation for program variables, either. Technically, if you mix gcc
and cc-compiled code in the same executable, there is no guarantee that
*that* would work either. That it works could be an accident of
implementation or a deliberate implementation decision, but it is not
architected by any published standard.

This is one area of standardization that is best left as part of an ABI
(or rather, an RBI - a relocatable binary interface).  An RBI will
specify how external variables are laid out, how symbols are encoded
(leading _ or not, what encryption algorithm, etc), and of course, the
relocatable object-file and debug information formats.

All compilers, linkers, debuggers, etc. on the system will have to
conform to such an RBI, if it exists and is standardized.

Such things (RBIs) are not very common (in its complete form, I mean) on
most systems today.  Until such time as RBIs are mandated by standards
bodies (like OSF or UI), you're s-o-l.

-----
Shankar Unni                                 Internet: shankar@iag.hp.com
HP International Contract Programming          HPDESK: Shankar UNNI / HP4700
Phone : +1-408-447-4007                          UUCP: ...!hplabs!hpda!shankar

DISCLAIMER:
This response does not represent the official position of, or statement by,
the Hewlett-Packard Company.  The above data is provided for informational
purposes only.  It is supplied without warranty of any kind.

In article <9598@s3.ireq.hydro.qc.ca> beaurega@ireq.hydro.qc.ca (Denis Beauregard) writes:
>MS C 7.0 is the last in the scene.  As it is not yet released, not
>data is available.  From above, compatibility could exist with

Unlike all others, MS incorporated appearences of "const" into name mangling
(correct move, I think).
--
Stefan Soyka                                     FAX:   +49 40 230 859
StarDivision (StarLab HH)                        Phone: +49 40 230 856
Heidenkampsweg 44                                uucp: ...!unido!starlab!ss
D-W-2000 Hamburg 1                               domain: ss@starlab.uucp

ss@starlab.UUCP (Stefan Soyka) writes:

>Unlike all others, MS incorporated appearences of "const" into name mangling
>(correct move, I think).

I don't understand this comment.  I don't know of any compiler in the
last 3 years which does not include const-ness in the name mangling.
--

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16

In article <1992Mar24.191030.6704@borland.com> pete@borland.com (Pete Becker) writes:
>>Unlike all others, MS incorporated appearences of "const" into name mangling
>>(correct move, I think).
>
> I don't know about "all others", but our compiler has always included
>constness in name mangling.

Sorry, I was typing faster than thinking. Not only Borland, but at least every
C++ compiler we use here includes the "const" property in the mangled
name. I confused it with the "private" and "protected" property.
MSC 7 generates qualified names for private and protected members and methods.
(Starlab is making single-source application software in C++ for Windows,
Macintosh and Unix/Motif, and we have used a number of compilers on each
platform.)
--
Stefan Soyka                                     FAX:   +49 40 230 859
StarDivision (StarLab HH)                        Phone: +49 40 230 856
Heidenkampsweg 44                                uucp: ...!unido!starlab!ss
D-W-2000 Hamburg 1                               domain: ss@starlab.uucp

>>>>> On 26 Mar 92 13:06:33 GMT, ss@starlab.UUCP (Stefan Soyka) said:

> MSC 7 generates qualified names for private and protected members and
> methods.

Why would it bother?  You can't have two names in a class definition that
differ in type only in that one is private and the other is protected
(therefore, you don't need the extra to differentiate two names).  Also C++
won't let you call a function that is not declared (in other words, the linker
doesn't have to figure out protected versus private because the compiler
already has).

Correct?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
Don't ever take a fence down until you know the reason it was put up.
-- G.K. Chesterton

In article <CIMSHOP!DAVIDM.92Mar29182410@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>>>>>> On 26 Mar 92 13:06:33 GMT, ss@starlab.UUCP (Stefan Soyka) said:
>
>> MSC 7 generates qualified names for private and protected members and
>> methods.
>
>Why would it bother?

 Presumably, to protect us from ourselves, so we can't

 #define private public

or perform some other such subversion of the type system.
 -- Pete

>>>>> On 30 Mar 92 17:05:56 GMT, pete@borland.com (Pete Becker) said:

> In article <CIMSHOP!DAVIDM.92Mar29182410@uunet.UU.NET>
> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>>>>>>> On 26 Mar 92 13:06:33 GMT, ss@starlab.UUCP (Stefan Soyka) said:

>>> MSC 7 generates qualified names for private and protected members and
>>> methods.

>>Why would it bother?

> Presumably, to protect us from ourselves, so we can't

>  #define private public

> or perform some other such subversion of the type system.

But wouldn't the qualified names that are generated be generated *after*
preprocessing?  Therefore, wouldn't:

 #define private public

 class A {
 private:
  int x;
 public:
  int y;
 };

wind up showing both x and y as public in the generated object module?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"Creative minds always have been known to survive any kind of bad training."
-- Anna Freud

Well, sometimes, anyway.
-- Mark Brader, utzoo!sq!msb

In article <CIMSHOP!DAVIDM.92Mar31104817@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>>>>>> On 30 Mar 92 17:05:56 GMT, pete@borland.com (Pete Becker) said:
>
>> In article <CIMSHOP!DAVIDM.92Mar29182410@uunet.UU.NET>
>> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>
>>>>>>>> On 26 Mar 92 13:06:33 GMT, ss@starlab.UUCP (Stefan Soyka) said:
>
>>>> MSC 7 generates qualified names for private and protected members and
>>>> methods.
>
>>>Why would it bother?
>
>> Presumably, to protect us from ourselves, so we can't
>
>>  #define private public
>
>> or perform some other such subversion of the type system.
>
>But wouldn't the qualified names that are generated be generated *after*
>preprocessing?  Therefore, wouldn't:
>
> #define private public
>
> class A {
> private:
>  int x;
> public:
>  int y;
> };
>
>wind up showing both x and y as public in the generated object module?


 Yes, that's the point.  If you use #define in that manner, you won't
able to link with a library that was compiled without the #define.  The idea
would be to make it harder for the user of a library to get around access
restrictions.  Personally, I'm not that paranoid.  If someone wants to try that
hard to beat the system, let 'em.  Their code probably won't work with the
next revision of the library, and that's what they deserve.
 -- Pete

In article <CIMSHOP!DAVIDM.92Mar31104817@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
|> In article <CIMSHOP!DAVIDM.92Mar29182410@uunet.UU.NET>
|> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
|
|> Presumably, to protect us from ourselves, so we can't
|
|>  #define private public
|
|> or perform some other such subversion of the type system.
|
|But wouldn't the qualified names that are generated be generated *after*
|preprocessing?  Therefore, wouldn't:

Yes, but:
|
|wind up showing both x and y as public in the generated object module?

the mangled names of functions in the object module would not match those
in the precompiled library providing those functions, so the object
module would not link.  This is what is meant by 'type-safe linkage'.
--
---------------
uunet!tdatirv!sarima    (Stanley Friesen)

In article <1057@racerx.UUCP> james@racerx.UUCP (James Montebello) writes:
>According to a number of sources, there is no "standard" on how a
>C++ compiler should mangle names....

Lots of good answers, to which I'll add that:

1) It is not the place of language specifiers to specify implementation,
and when they do so they are making a mistake.  A language is something
very different from its implementation.

2) This is not a new problem.  The same problems existed when first C compilers
became available from a number of sources.  The problem became solved because:
a) operating system vendors began to ship libraries in a format particular
 to that particular operating system.
b) compiler vendors began to support that format -- or they couldn't effectively
 play on that operating system.

Now it might be somewhat annoying that there might be say two different 68000
operating system with two different .obj formats -- but, the two different .obj
formats are the least of the problem -- a bigger part of the problem is
that the underlying design assumptions of the operating systems are so different
that even porting *source* code between the two operating systems is very
very difficult!  And why are the operating systems so very very different?
Because different people have different ideas about what the best way is
to do the job -- and what the job even is.  So this is not a problem that's
going away any time soon.

Also, note that some consortiums *have* gone to some effort to allow some
binary porting of .objs and .libs between different vendor's systems.
But, this just goes to show this isn't a *language* specification problem,
but is an issue for standardization in an entirely different domain,
such as within a multi-vendor industry-driven standardization effort.