home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c++:11232 comp.std.c++:895
- Newsgroups: comp.lang.c++,comp.std.c++
- Path: sparky!uunet!ftpbox!motsrd!news
- From: shang@corp.mot.com (David (Lujun) Shang)
- Subject: Re: Language extensions for run-time type identification
- Message-ID: <1992Jul21.143131.6902@cadsun.corp.mot.com>
- Sender: news@cadsun.corp.mot.com
- Reply-To: shang@corp.mot.com
- Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
- References: <14ft2uINNjh4@agate.berkeley.edu>
- Date: Tue, 21 Jul 92 14:31:31 GMT
- Lines: 48
-
- In article <14ft2uINNjh4@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe
- Buck) writes:
- > * the virtual impossibility of designing a more general solution that does
- > not break compatibility with C structs (a requirement that may be
- > meaningless to theoretical folks but that is nevertheless vital).
- > This constraint forbids adding any data to the object of any kind.
- >
- The object code does not necessarily include any code about the type
- information. Encoding vtable references into object code is a particular way
- applied by the current C++ implementation. For a complete solution to run time
- type check, this technique must be changed. I've mentioned several times, the
- "tagged pointer" technique is the proper way to achieve this goal. Only those
- polymorphic pointers need to be tagged (not all pointers). The tagged pointer
- is not an overhead since it already eliminates the necessity to tag an object.
-
- > * the fact that it is trivial to force any class for which run-time type
- > identification is needed to have a virtual function table (simply add
- > a virtual destructor).
- >
- Adding something virtual just for the purpose that has nothing to do with it?
-
- > In most implementations of classes with virtual functions, each object
- > already has, in effect, a type-ID: the pointer to the virtual function
- > table. This is a natural hook on which to hang run time type checking.
- >
- The pointer to vtable can not work as a type-ID for a language with multiple
- inheritance. An object of particular class derived from multiple bases may
- contain serveral different vtable references. Different base pointers to the
- same object may use different vtable pointers.
-
- > I could also argue the other way: for a debugger, it isn't enough to
- > identify all class objects. I also need to be able to identify the
- > types of any int, double, pointer, or reference variables. There's no
- > inherent reason why being able to identify all classes, but no other
- > variable types, is a more natural or useful division that just being
- > able to identify objects that have virtual functions.
- >
- I fully agree with you when you argue the other way. In fact, it is possible
- and practicable to identify any types and classes, no panelty on object codes,
- especially for those objects of conventional C types. The only panelty is an
- additinal integer (used as internal type identifier) for each type or class.
- But we can benefit a lot: integrating conventional C types into class hierarchy
- without additional overhead, explicit run time type check to prevent all the
- type error at compile time, type-safe cast, to solve problem with "sizeof"
- operator, problem with pointer increasement and decreasement, problems with
- covariant type in derived classes, and many many other interesting things.
-
- David Shang
-