Proposal for mangling template partial specializations.

John Wilkinson jfw at sgi.com
Tue Apr 18 19:03:17 UTC 2000


-- 
John Wilkinson
-------------- next part --------------
I have come to the somewhat reluctant conclusion that attempting
to diagnose this kind of error through name-mangling would be a mistake.
If other ways can be found, I think they should probably be left to
individual implementations and not made part of the ABI (but I am less
committed to this point:  I have not, however, thought of any promising
approach to this).

(1)  If the standard requires no diagnostic for a violation of the rules,
then certainly  a standard-conforming implementation is permitted to
link and execute the program.  (1.4, Paragraph 2).  So this is a
quality-of-implementation issue, not a standard-conformance issue.

(2)  As Mark points out, if we use mangling to distinguish
specializations from instantiations, the resulting diagnostics may
be hard to interpret.  I regard this as less important, however, than

(3)  Providing distinct manglings may just allow definitions to coexist
that are  forbidden from doing so.   So it doesn't solve the problem
of providing a diagnostic for this error; it only does so for one
flavor of the error.

(4)  The specific mangling scheme that Colleen proposes does not
distinguish all the necessary variants.  Consider the declarations

   template <class T> struct X     {void foo();};

   template <class T> struct X<T*> {void foo();};

   template <> struct X<int*>      {void foo();};

A program that declares

  X<int*> x;

and invokes x.foo()

will thereby reference a function with the signature

  void X<int*>::foo(void).

Three different functions can be invoked, depending on whether the
program includes just the first declaration, just the first and second, or
the first and third (with or without the second).  Colleen's mangling
scheme clearly distinguishes the first and third cases, but for the
second case is forced to pick one of the other two manglings.  It
cannot distinguish all three.


More information about the cxx-abi-dev mailing list