In article <4fdsql$e6m@jabba.lehman.com>, ajay@lehman.com (Ajay Kamdar) wrote:

[Snip]

> The compiler generates all this meta data for itself, and unfortunately
> throws it all away rather than allowing access to it
> programmatically. With in the last five years I have worked on three
> separate projects where the availability of meta data from
> the compiler itself would have saved us very significant amounts of
> time and money inventing elaborate meta data generation mechanisms of
> our own.
>
> I don't remember any discussion in this forum as to why the standards
> committee limited RTTI information to its current form. Did the
> committee ever consider standardizing more detailed RTTI?
> Were there technical problems which prevented such standardization?

A better support of persistence was also the intention of my original post.
But I did not ask for the additional information in RTTI because I knew
already the reason:

This wide RTTI would allow anybody with a decent disassembler to reverse-
engineer your valuable data structures, including full member variable
names. This cannot be acceptable for a general-purpose (not only persistence)
feature.

Most compilers have an option to generate your extended information,
either as a MAP file or for symbolic debugger support. So you can extract
your information and include it yourself, if you want.

The distinct name()s (at least for class objects) are still needed to get
the connection to the external information. I use a compiler which emits
perfectly mangled symbols for the debugger, but RTTI gives only a short
version of this (inner name of nested class). So you have no chance to
differentiate between list<foo>::iterator and vector<bar>::iterator, because
all you get is "iterator".


Dirk

------------------------------------------------------------------
Dirk Becker                                dirk@becker.adviser.com
Harderweg 76, 22549 Hamburg, Germany          Tel. +49 40 80783143
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

dirk@becker.adviser.com (Dirk Becker) writes:

>A better support of persistence was also the intention of my original post.
>But I did not ask for the additional information in RTTI because I knew
>already the reason:

>This wide RTTI would allow anybody with a decent disassembler to reverse-
>engineer your valuable data structures, including full member variable
>names. This cannot be acceptable for a general-purpose (not only persistence)
>feature.

Just whose reason was that? So far as I know, no such discussion ever
took place in the C++ Committee.

No proposal has ever been turned down on the basis of it making code
easier to reverse-engineer or disassemble. I know of no serious
discussion within the C++ Committee where such a subject was even raised.

So far as I know, no complete proposal for providing support for
persistence was ever presented.

The difficulty lies in devising a scheme that is portable, implementable,
useful, and also acceptable to a wide range of implementors and users.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Hi!

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?

Dirk

------------------------------------------------------------------
Dirk Becker                                dirk@becker.adviser.com
Harderweg 76, 22549 Hamburg, Germany



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

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

In article <xsorawcazry.fsf@avs.cs.rpi.edu>,
David Vandevoorde <vandevod@cs.rpi.edu> wrote:
>
>>>>>> "BG" == Bill Gibbons <bgibbons@best.com> writes:
>[...]
>BG> There is some chance that some canonical form will be recommended
>BG> in a non-normative annex in the standard.
>
>There was a thread here some time ago concluding that RTTI would be
>considerably more convenient for purposes of object persistence and
>transportation if this could be standardized somehow.

Standardizing the return value of name() helps, but only a little.
RTTI would be considerably more convenient for the purposes of
object persistence and transportation if it also included the
following object layout information:

    + Information about data members.
      For each data member, this information would consist of
   # data member typeinfo
   # data member name
   # isAPointer? (number of indirections if yes)
   # isAReference?
   # raw offset from start of immediately containing object
     (This would be of course compiler and platform specific.
      But that is _exactly_ what is required.)

    + Information about base classes
      For each base class, this information would consist of
   # base class typeinfo
   # virtual derivation?
   # raw offset from start of deriving class; offset to
     the actual sub-object is a virtual base class

    + Virtual destructor?


base classes were
   # access protection (public/protected/private)
   # type of derivation (public/protected/private)


This list is probably not exhaustive, but would be a good first start.

The compiler generates all this meta data for itself, and unfortunately
throws it all away rather than allowing access to it
programmatically. With in the last five years I have worked on three
separate projects where the availability of meta data from
the compiler itself would have saved us very significant amounts of
time and money inventing elaborate meta data generation mechanisms of
our own.

I don't remember any discussion in this forum as to why the standards
committee limited RTTI information to its current form. Did the
committee ever consider standardizing more detailed RTTI?
Were there technical problems which prevented such standardization?
--
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]