In <4rhgqt$lv5@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

>C++ is younger than C, and has more degrees of freedom (where do
>virtual base classes go, how do you call a virtual function, what
>is the exception mechanism, what is the template mechanism), and on
>most platforms has not yet been standardized. Because there is no
>one best impelementation of these features, compilers differ on
>at least some of them. The differences in name mangling alert you
>to the incompatibility of the object code.

That is of course a killing argument. What I've forgotten completly was
inheritance from classes defined within the DLL or the way around. Then
you'll end up with vtable problems and all this stuff.

>Look for more stability as the C++ standard stabilizes, and for
>standard interface definitions to appear for each platform. At that
>point you will be able to link code from different compilers.

I realy don't believe that will happen. I'd rather ask the library creators to provide
different DLL's for different compilers.

Thanks for pointing those problems out.

Ronny
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Alastair G. M. Milne" <milne@speed.net> writes:

>Fergus Henderson <fjh@cs.mu.oz.au> wrote:
>
>> Since this has been posted to comp.std.c++, I will tell you what the
>> C++ standard says about this: nothing.
>
>I am just now in the process of trying to catch up on what standards there
>are for C++ (I hadn't noted the .std newsgroup before).  I was under the
>impression that the most that exists right now is a draught of a standard?
>(I have a copy of that one in PDF form.)  Is this the one that's being
>called "the" standard?  Sorry I don't have its version number at hand,
>but if memory serves it's from January 1996.

Apologies for my sloppy terminology.  There is as yet no such thing as
the C++ standard.  What we have currently is a regularly updated
"Working Paper".  Under the ISO standards process, as the committee's
work progresses, they release this working paper as one or more
"Committee Drafts", a "Draft International Standard", and then finally
it is published as an "International Standard".  The C++ committee have
produced a Committee Draft, but they have not yet produced a Draft
International Standard.  Strictly speaking, this means that one should
not yet refer to even "the draft C++ standard", let alone "the C++
standard".  I should have said "the ANSI/ISO C++'s committee's latest
working paper says...".

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hy C++ Developers!

I have a problem concerning the following facts:

(1.) A C++ compiler generates function names that include an encoding of the
function's argument types. This is known as name mangling.
(2.) There is no general standard for name mangling. Although all C++
compilers incorporate name mangling, no two do it the same way.
(3.) You can avoid name mangling by declaring the functions as extern "C"; but
you can do this for only one of a set of functions with the same name (no
function overloading possible)

=> You can't call e.g. a Borland developed DLL from a MS developed Exe!

Is there any solution (unless you don't want to provide one DLL version for
each compiler system)?

Thanks.
Frank.
(frank.thelen@pinneberg.netsurf.de)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article a66@news.shlink.de,  frank.thelen@pinneberg.netsurf.de (Frank G. Thelen) writes:
>I have a problem concerning the following facts:
>
>(1.) A C++ compiler generates function names that include an encoding of the
>function's argument types. This is known as name mangling.
>(2.) There is no general standard for name mangling. Although all C++
>compilers incorporate name mangling, no two do it the same way.
>(3.) You can avoid name mangling by declaring the functions as extern "C"; but
>you can do this for only one of a set of functions with the same name (no
>function overloading possible)
>
>=> You can't call e.g. a Borland developed DLL from a MS developed Exe!
>
>Is there any solution (unless you don't want to provide one DLL version for
>each compiler system)?

Different compilers use different name mangling because their object
code is incompatible, not the other way around. The ARM discusses
this problem, and recommends using different name mangling to prevent
linking object modules that are not otherwise compatible.

If you could get the modules to link by re-mapping the names, the program
would not run, because the compilers would use different object layouts and
different function calling conventions.

The problem is not unique to C++. You can find the same problem among
C (or Fortran, or Cobol, or Basic) compilers on the same system.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[This thread is cross-posted; please be careful that any followups
are appropriate for all the groups you post to.]

frank.thelen@pinneberg.netsurf.de (Frank G. Thelen) writes:

>I have a problem concerning the following facts:
>
>(1.) A C++ compiler generates function names that include an encoding of the
>function's argument types. This is known as name mangling.
>(2.) There is no general standard for name mangling. Although all C++
>compilers incorporate name mangling, no two do it the same way.
>(3.) You can avoid name mangling by declaring the functions as extern "C"; but

>you can do this for only one of a set of functions with the same name (no
>function overloading possible)
>
>=> You can't call e.g. a Borland developed DLL from a MS developed Exe!

Since this has been posted to comp.std.c++, I will tell you what the
C++ standard says about this: nothing.  It is not the job of the C++
*language* standard to specify binary compatibility requirements
between different C++ compilers.  That would be the job of a C++ ABI
(application binary interface) standard for a particular platform.  I
believe Sun are in the process of developing such an ABI standard,
although I don't know of any other companies or organizations that are
doing that yet; it's a bit difficult to develop an ABI standard while
the language standard is still subject to change.

Note that naming mangling is really the least of your problems
in this respect.  To quote the FAQ list for gnu.g++.help:

| Why can't g++ code link with code from other C++ compilers?
| ===========================================================
|
|    "Why can't I link g++-compiled programs against libraries compiled by
| some other C++ compiler?"
|
|    Some people think that, if only the FSF and Cygnus Support folks
| would stop being stubborn and mangle names the same way that, say,
| cfront does, then any g++-compiled program would link successfully
| against any cfront-compiled library and vice versa.  Name mangling is
| the least of the problems.  Compilers differ as to how objects are laid
| out, how multiple inheritance is implemented, how virtual function
| calls are handled, and so on, so if the name mangling were made the
| same, your programs would link against libraries provided from other
| compilers but then crash when run.  For this reason, the ARM
| *encourages* compiler writers to make their name mangling different
| from that of other compilers for the same platform.  Incompatible
| libraries are then detected at link time, rather than at run time.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <4r8qgb$dvd@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

>Different compilers use different name mangling because their object
>code is incompatible, not the other way around. The ARM discusses
>this problem, and recommends using different name mangling to prevent
>linking object modules that are not otherwise compatible.
>
>If you could get the modules to link by re-mapping the names, the program
>would not run, because the compilers would use different object layouts and
>different function calling conventions.

I agree with you as far as you're talking about static libraries, but how about DLL's ?
They are containing a completly separated environment and must not have any
external resolves except to other DLL's. I don't think there is any interference by
calling a Borland DLL from a Watcom compiler of whatever. Of course name
mangling prevents this from happen but it shouldn't.

Ronny
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Ronny Bremer (RBREMER@future-gate.com) wrote:
: In <4r8qgb$dvd@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

: I agree with you as far as you're talking about static libraries, but how about DLL's ?
: They are containing a completly separated environment and must not have any
: external resolves except to other DLL's. I don't think there is any interference by
: calling a Borland DLL from a Watcom compiler of whatever. Of course name
: mangling prevents this from happen but it shouldn't.

Assuming, of course, that they are using the same calling
conventions.  Taking your example further, Watcom's default calling
convention passes parameters in registers, while Borland pushes
parameters onto the stack.

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

RBREMER@future-gate.com   (Ronny Bremer) writes:

>In <4r8qgb$dvd@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve
>Clamage) writes:

>>Different compilers use different name mangling because their object
>>code is incompatible, not the other way around. The ARM discusses
>>this problem, and recommends using different name mangling to prevent
>>linking object modules that are not otherwise compatible.
>>
>>If you could get the modules to link by re-mapping the names, the program
>>would not run, because the compilers would use different object layouts and
>>different function calling conventions.

>I agree with you as far as you're talking about static libraries, but how
>about DLL's ? They are containing a completly separated environment and must
>not have any external resolves except to other DLL's. I don't think there
>is any interference by calling a Borland DLL from a Watcom compiler of
>whatever. Of course name mangling prevents this from happen but it shouldn't.

In other words, the compiler will generate one form of function call
and class layout if the destination of the object file is a DLL,
and different forms of function call and class layout otherwise?
The compiler couldn't generate a call to a function or find an element
of a class unless it knew whether it was located in a DLL.

That clearly makes no sense, and of course is not the case.

You are probably finding that C functions and data have a mandated
interface, and all C compilers generate object code and data
layouts in a compatible way, DLL or not. That was not always the
case, and it used to be common on MSDOS systems to need different
versions of libraries for each different C compiler. Code compiled
by compiler X would not work with code compiled by compiler Y.
The market has matured, and object files now tend to be compatible.

C++ is younger than C, and has more degrees of freedom (where do
virtual base classes go, how do you call a virtual function, what
is the exception mechanism, what is the template mechanism), and on
most platforms has not yet been standardized. Because there is no
one best impelementation of these features, compilers differ on
at least some of them. The differences in name mangling alert you
to the incompatibility of the object code.

In fact, it has been traditional, due to the changing nature of
the defintion of C++, for major compiler releases to generate
code incompatible with earlier releases from the same vendor.
The vendor would therefore change the name mangling to prevent
linking incompatible code.o

Look for more stability as the C++ standard stabilizes, and for
standard interface definitions to appear for each platform. At that
point you will be able to link code from different compilers.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

tony@online.tmx.com.au (Tony Cook) writes:

>Ronny Bremer (RBREMER@future-gate.com) wrote:
>
>: I agree with you as far as you're talking about static libraries, but how
>: about DLL's ?
>: They are containing a completly separated environment and must not have any
>: external resolves except to other DLL's.  I don't think there is any
>: interference by calling a Borland DLL from a Watcom compiler of whatever.
>: Of course name mangling prevents this from happen but it shouldn't.
>
>Assuming, of course, that they are using the same calling
>conventions.

That is just one of many, many issues that can cause problems.
Others include the same implementation method for exeption handling;
the same alignment requirements and data representation for any data
passed, e.g. the same sizes of basic data types such as `int'),
the same way of implementing virtual functions, the same way of implementing
multiple inheritence, the same way of implementing virtual base classes,
the same way of implementing RTTI, and so on; the same way of handling
constructors and operator new; compatibility of run-time libraries;
and probably another half a dozen issues I haven't mentioned.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson <fjh@cs.mu.oz.au> wrote:

> Since this has been posted to comp.std.c++, I will tell you what the
> C++ standard says about this: nothing.

I am just now in the process of trying to catch up on what standards there
are for C++ (I hadn't noted the .std newsgroup before).  I was under the
impression that the most that exists right now is a draught of a standard?
(I have a copy of that one in PDF form.)  Is this the one that's being
called "the" standard?  Sorry I don't have its version number at hand,
but if memory serves it's from January 1996.

Alastair Milne

========================
+ Alastair Milne
>  from CSUSM: amilne@coyote.csusm.edu
>

+ otherwise:  milne@speed.net
>
+ FAX:                        (714) 240-6229
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <Du1K28.59B@online.tmx.com.au>, tony@online.tmx.com.au (Tony Cook) writes:

>Assuming, of course, that they are using the same calling
>conventions.  Taking your example further, Watcom's default calling
>convention passes parameters in registers, while Borland pushes
>parameters onto the stack.

Indeed. However this is first guaranteed be different export names (with or
without a trailing '_') and second you'll be faced with the same problem when
linking two Watcom libraries with different calling conventions.

Ronny


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage (clamage@Eng.Sun.COM) wrote:
| You are probably finding that C functions and data have a mandated
| interface, and all C compilers generate object code and data
| layouts in a compatible way, DLL or not. That was not always the
| case, and it used to be common on MSDOS systems to need different
| versions of libraries for each different C compiler. Code compiled
| by compiler X would not work with code compiled by compiler Y.
| The market has matured, and object files now tend to be compatible.

This paints a somewhat false picture.

Object files tend to be compatible merely because C implementations do not
use name mangling.  However, link-compatible object files almost never
lead to working applications without many further steps being taken.

It always seems to come as a surprise to many C++ people that problems
of mixed implementations exist in the C language almost as much as they do
in the C++ language.  In many cases, an application comprising code
compiled with multiple C implementations may link, but will fall over at
runtime because of a calling convention mismatch, a structure padding
mismatch, inappropriate or uninitialised runtime library support, or
mismatched distance attributes.

In general, the situation with C is pretty much as bad as the situation
with C++.  C++ programmers are misled into believing that C does not have
problems with mixed implementations by the existence of `extern "C"' in
their language.  This gives them a false sense of security, as well as an
incorrect perception of the C language.  Many is the time that I have had
to patiently explain to a C++ programmer that using `extern "C"' will *not*
make their functions callable from all C and C++ compilers.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4rtuij$old@silver.jba.co.uk>, JdeBP@jba.co.uk (Jonathan de
Boyne Pollard) writes:

|> Steve Clamage (clamage@Eng.Sun.COM) wrote:
|> | You are probably finding that C functions and data have a mandated
|> | interface, and all C compilers generate object code and data
|> | layouts in a compatible way, DLL or not. That was not always the
|> | case, and it used to be common on MSDOS systems to need different
|> | versions of libraries for each different C compiler. Code compiled
|> | by compiler X would not work with code compiled by compiler Y.
|> | The market has matured, and object files now tend to be compatible.
|>
|> This paints a somewhat false picture.
|>
|> Object files tend to be compatible merely because C implementations do not
|> use name mangling.  However, link-compatible object files almost never
|> lead to working applications without many further steps being taken.
|>
|> It always seems to come as a surprise to many C++ people that problems
|> of mixed implementations exist in the C language almost as much as they do
|> in the C++ language.

I suspect that you are right that this would come as a surprise, as
many C++ users are former C users, and their experience there was quite
different.  The harder problems in C++ (exception handling, RTTI,
structure layout under inheritance, esp. with virtual base classes,
etc.) simply do not exist in C.  True, one _can_ fiddle around with
structure layout or whatever, but you're going to have a hard time
proving that yours is so much better that it justifies the
incompatibility.

While I'm inveighing on the subject, let me add that I think C++
compiler writers have slipped into a protectionist mode of thinking
that is neither in their interest, nor in their users'.  For users not
requiring advanced language features, the incompatibility of object
modules is an unnecessary obstacle rather arbitrarily introduced by the
compiler writers.  To claim that changing the name-mangling scheme
"from release to release" is a feature beggars the imagination.  By the
same argument, Sun should change the names of all the syscalls on
Solaris because, while some of them are the same, some of them behave
differently for some cases, and some are completely different.  (I hope
I'm not giving Sun ideas here.) Incompatibility for its own sake will
only discourage users from using C++.

On the other hand, given the baroque complexity that the DWP promises,
maybe that's a Good Thing.

 glenn

8<==============================================
Glenn Carroll     glenn@ims.uni-stuttgart.de
Institut fuer Maschinelle Sprachverarbeitung
Azenbergstr. 12
70174 Stuttgart     (49)711-121-1387  office
Germany      (49)711-121-1366  fax
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

glenn@ims.uni-stuttgart.de (Glenn Carroll) writes:

>To claim that changing the name-mangling scheme
>"from release to release" is a feature beggars the imagination.  By the
>same argument, Sun should change the names of all the syscalls on
>Solaris because, while some of them are the same, some of them behave
>differently for some cases, and some are completely different.  (I hope
>I'm not giving Sun ideas here.)

I don't know for sure what Sun do, but I do know that the Linux kernel
developers change the system call number for a system call whenever any
change is made to the interface of that system call that is not
backwards binary compatible, and I suspect that Sun probably do
something similar.  Of course, in both cases (C++ interfaces or OS
interfaces), the name used in the source code doesn't change, only
the "under-the-hood" implementation details -- the mangled name,
or the system call number -- change.

Obviously changing the binary interface from release to release
is something that should be avoided if possible, but often it is
not possible.  Sometimes the interface needs to change in order
to fix bugs, to improve performance, or to implement new features.

If the binary interface does change, for whatever reason, then
I would much rather the system report any incompatibilities,
rather than having programs just misbehave or crash.

It would certainly be a good idea to standardize the ABIs as well as
standardizing the source, but the latter is pretty much a prerequisite
for the former, and we still don't have a C++ standard yet.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

glenn@ims.uni-stuttgart.de (Glenn Carroll) writes:

>While I'm inveighing on the subject, let me add that I think C++
>compiler writers have slipped into a protectionist mode of thinking
>that is neither in their interest, nor in their users'.  For users not
>requiring advanced language features, the incompatibility of object
>modules is an unnecessary obstacle rather arbitrarily introduced by the
>compiler writers.  To claim that changing the name-mangling scheme
>"from release to release" is a feature beggars the imagination.

Evidently you have little familiarity with the history of C++.

Major releases of C++ had changes in the language definition which
required changes in name mangling, desires of implementors and users
aside.

Example 1:
When type-safe linkage was added to C++, name mangling was requried for ALL
functions, not just those which were declared with "overload". The function
whose name was formerly unmangled had to become mangled. The change in
the language rules left no choice in that matter. If you put function
foo(int) in a library, the compiler and linker cannot know whether you or
someone in the future may create another function foo, and so must mangle it
in a predictable way.

Example 2:
When multiple inheritance was added to the language, the implementation
of virtual function calls had to change for all classes, even those that
did not use multiple inheritance. Given only
 class C { public: virtual int f(); };
 int foo(C* c) { return c->f(); }
the compiler cannot know whether foo will be called with a pointer to a
class type which has C as one of multiple bases. It must genreate a
single style of virtual function call which works with single and with
multiple inheritance.  That style cannot be the same as before, which
worked only with single inheritance. A cruel compiler implementor would
leave name mangling alone, allowing programs to link which could not
run. An implementor who cared about his clients would change the name
mangling.

Example 3:
When nested types were added to the language, name mangling had to change
again. Consider
 class A {
 public:
     class B { ... };
 };
The name of class B was no longer "B", but "A::B". The mangling of any
function name which had B involved in a parameter type had to change,
because there could now be other types in the program also called "B", and
the names had to be distinguished.

Example 4 ... N:
When nested templates were added to C++, mangling of template names had
to change in detail. ... Details of the specialization of templates are
still being worked out; pioneers in implementing templates might well
need to alter name mangling to match. ... A proposal is being considered
to make the linkage of a function (extern "C", for example) part of the
function type. That will require a change in name mangling of parameters
having pointers to such functions. ... and so on ...

Instead of assuming that compiler implementors are malicious and enjoy
toturing their clients, why not ask yourself whether there might be
a valid reason for something you don't understand? Or ask the
implementors. They are usually happy to explain the reason for changes
that make your life more difficult, because it makes their lives even more
difficult. They wouldn't do it if they didn't have to.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]