🚀 go-pugleaf

In article <v01530500ad36a19a2831@[194.163.74.11]>,
dirk@becker.adviser.com (Dirk Becker) wrote:

> Is there any detailed specification added to the name() member of
> type_info objects or is it still just implementation dependent?
> 
> Why not ensure to have distinct names for different classes?
> Could it be possible to have even distinct name()s for nested classes
> bearing the same name but different enclosing classes?
> What about classes with the same name but in different namespaces?
> Or is "9.10 Nested type names" [class.nested.type] even applied to
> RTTI names?

The original RTTI papers imply that the complete name, together with any
qualification and/or template arguments, should be used.  For example:

    mytemplate<X>
    mynamespace::outer::inner

But the papers did not explicitly specify how this was to be done, so the
current draft leaves that implementation dependent.

I wrote a proposal for standardizing the names, but there was only
lukewarm interest.  This is partly because there are some problems:

  * Function parameter types:

         does --typeid(void (*)(int,int).name()-- yield

               "void (*)(int,int)"
          or   "void(*)(int, int)"
          etc.
         (possible answer - just specify a canonical form)

  * Template arguments:

         does --typeid(T<A,B>).name()-- yield

               "T<A,B>"
          or   "T<A, B>"
          etc.
          (possible answer - just specify a canonical form)

  * How are unnamed types handled?  For example:

         struct { int x; } y;
         typeid(y).name();
         (possible answers - implementation dependent
                             invented names based on ordinals)

  * How are local types handled?  For example:

         void f() { struct A { }; typeid(A).name(); }
         void g() { struct A { }; typeid(A).name(); }

         Are these two names the same?
         (possible answers - yes, they are the same
                             implementation dependent
                             invented names based on function signature
                               but only unique for external functions)

There is some chance that some canonical form will be recommended
in a non-normative annex in the standard.

-- 
-- Bill Gibbons
   bgibbons@best.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]