In article <4s2t0j$s67@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:

|> Evidently you have little familiarity with the history of C++.
|>
I know enough to make some evaluation of the examples you gave, but
admittedly that doesn't take much.

Example 1 (type-safe linkage) was introduced so long ago it did not
require many compilers to change.  Certainly Sun's C++ compiler did not
exist at the time--Sun's first C++ compiler was based on AT&T's cfront,
and by the time Sun bought it, example  2 (multiple inheritance) was also
taken care of.

Example 3 (nested types) is a fine specimen of the sort of changes which need not and should not affect users who do not exploit a particular language featuure.  Users should get a "caveat emptor" warning, but they shouldn't
be locked out of libraries which in fact make no use of nested types.

Example 4 .. N (nested templates, template specialization, etc) is largely
speculative.  Certainly some of the items mentioned will find reasonable
solutions involving incompatible changes, but this is hardly surprising.
Other items on the list (and the function linkage example looks particularly
promising in this regard) look more like they won't require incompatibility,
but the compilers may nonetheless introduce it due to corporate policy or
someone just having a Bad Day.

So I see no evidence from the examples that incompatible linkage is often justified.  To recap:  the first example is before the first release of most
C++ compilers, so it required no incompatible linkage maneuvering.  The fourth
example lies in the future, so it hasn't bothered users yet.  Example 3 fulfills my requirements--no mandatory incompatibility.  That leaves example 2, one case of incompatible linkage in the history of C++ to date.  I'm quite
happy with one incompatible release.  The defense rests.

|> 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 ...
|>
|
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                             ]

In article MAA16534@schwalbe.ims.uni-stuttgart.de, Glenn Carroll <glenn@IMS.Uni-Stuttgart.DE> writes:
> Example 1 (type-safe linkage) was introduced so long ago it did not
> require many compilers to change.  Certainly Sun's C++ compiler did not
> exist at the time--Sun's first C++ compiler was based on AT&T's cfront,
> and by the time Sun bought it, example  2 (multiple inheritance) was also
> taken care of.

The change occurred with cfront based compilers, which were, at the time, almost
the only C++ compilers.  You could say that it didn't cause many compilers to
change, or you could say that it caused all of them to change.  Both statements
were true.

MI caused more problems than that, because the first implementations has a bug
that caused classes with virtual bases to become very much larger than they
had to be.  Some versions of cfront kept this bug, maintaining compatibility at
the cost of high memory usage, while others did not.  Guess which ones the
customers preferred.  (Hint, most customers don't like 10x higher memory usage.)

> Example 3 (nested types) is a fine specimen of the sort of changes which need not and should not affect users who do not exploit a particular language featuure.  Users should get a "caveat emptor" warning, but they shouldn't
> be locked out of libraries which in fact make no use of nested types.

And they weren't.  Those who used nested, types, however, did have problems.

> Example 4 .. N (nested templates, template specialization, etc) is largely
> speculative.  Certainly some of the items mentioned will find reasonable
> solutions involving incompatible changes, but this is hardly surprising.
> Other items on the list (and the function linkage example looks particularly
> promising in this regard) look more like they won't require incompatibility,
> but the compilers may nonetheless introduce it due to corporate policy or
> someone just having a Bad Day.

Not speculative.  The changes absolutely require mangling changes.  This was discussed
among the implementors who are on the ANSI/ISO committee (essentially all of them)
and we decided that we could live with it.  There were enough changes in other
areas (bool, for example) that there seemed to be no way to avoid incompatibility
anyway.

> So I see no evidence from the examples that incompatible linkage is often justified.

Unfortunately, this just means that you haven't looked hard enough.  Sorry, but
implementors do NOT like breaking their customers' code.  You can assume that they
do if that makes you feel better, but the plain fact is that we go to great
lengths to avoid breaking customer code.

Sun, for example, as avoided adding a number of new features that would break
binary compatibility.  We will release them all at once, with a flag to use
the compiler in "backward compatibility mode" when needed.  We had thought that
the standard had reached a stable enough point that we could do this, but the
last meeting just approved a change (unfortunately necessary, in my opinion) that
required yet another change in name mangling.

We have been promising this "one massive change" for a couple of years and have
had to hold off release after release.  I sincerely hope that we can finally
deliver.

A dose of reality, rather than opinion and assumption, would help your case.

If you really want nightmares, think about the new standard library.  Nobody
doubts that it will be buggy and require a large number of changes in the
first years of its life.  After all, it's never been implemented yet.  Would
you like to bet how many of those changes will cause interface changes?

A stable ABI?  Don't make me laugh. :-(

---
Michael Ball
SunSoft Development Products




[ 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                             ]