🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Dirk Becker Sat, 10 Feb 1996 15:38
Re: Make type_info name() distinct?
#3283
Author: Dirk Becker
Date: Sat, 10 Feb 1996 15:38
47 lines
2793 bytes
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. ]
Re: Make type_info name() distinct?
#3284
Author: Steve Clamage
Date: Sun, 11 Feb 1996 03:20
29 lines
1898 bytes
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. ]
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads