home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c++:11754 comp.std.c++:991
- 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: <1992Jul29.192054.22533@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: <BryFLI.Hz2@world.std.com>
- Date: Wed, 29 Jul 92 19:20:54 GMT
- Lines: 87
-
- In article <BryFLI.Hz2@world.std.com> wmm@world.std.com (William M Miller)
- writes:
- >
- > Consider this: dynamic typing is only required when you've "lost" the
- > exact type of the object to which an expression refers. In all other
- > cases, the static type of the expression is sufficient, and the
- > compiler can just provide a direct reference to the typeinfo if the
- > program requests type information.
- >
- Definitely true.
-
- > There are only two ways to "lose" the exact type in C++ (apart from
- > explicit casting to an unrelated type, for instance): conversion of a
- > pointer/reference to a derived class into a pointer/reference to a
- > base class, and conversion to void*.
- >
- Also True, but only within a domestic environment.
-
- > Doing something about the latter
- > is either very expensive or requires breaking compatibility with C
- > void* pointers (tagged pointers),
- >
- True, if you do not relate the void* to the tagged pointer. Only those
- polymorphic pointers need to be tagged. void* is not a polymorphic pointer. If
- we want an equivalent polymorphic pointer, we can introduce a new one:
- anytype*, where anytype is supposed to be the root of class hierarchy. You get
- penalty only when you use it.
-
- > so realistically we are talking
- > about a requirement for RTTI that *only* has to deal with the results
- > of derived-to-base conversions.
- >
- Not exactly. It is true within a domestic environment.
-
- > The question, then, is under what circumstances do such conversions
- > occur? The premise of the current proposal is that you don't *do*
- > such conversions unless you have provided for polymorphic behavior,
- > i.e., virtual functions. Inheritance for factoring and sharing of
- > representation and code is fine, but in such applications you
- > typically don't rely on derived-to-base conversions.
- >
- Not entirely true even for a domestic system:
-
- I often have a class hierachy in which the base methods manipulate only on the
- part of the base data and no virtualization is required. All the specific
- operations in the derived classes will be performed from the specific
- interfaces. But I still need a general interface that manipultes all of the
- object at the base level. Virtual functions can help a lot in reducing the
- neccessity of downcast and hence the need of RTTI. But virtual function does
- not always help. Sometimes the specific interfaces and requirements can vary
- greatly in derived classes, it is impossible to exract a common interface as a
- virtual interface. In this case, I have to use RTTI rather than the virtual
- function.
-
- > The challenge, then, for those who view RTTI-via-vtable as
- > insufficient is to provide *concrete* counterexamples to this
- > assumption: applications where derived-to-base casting does occur
- > without the need for virtual functions and for which RTTI would
- > nevertheless be useful. Are there such applications?
- >
- Yes.
-
- I can maintain a group of passive objects without intrinsic behavioral
- characteristics, needless to say any virtual functions. What I am concerned is
- only the internal data structure. These objects are usually used to carry the
- information and to be transfered between different environments. I need RTTI to
- represent or transform these objects correctly. For example, to transform an
- integer in an object from Intel 8086 form to network form. Although a simple
- type id is usually insufficient for this case, but it provides a key to access
- the detail type information in some type library generated by the compiler (I
- just hate to see the game of waste: inventing one precompiler after another).
-
- My multitasking system can also have an interface that take an object as input
- from other task. Such object is not necessarily virtualized. Such type check is
- usaually performed at run time. Without RTTI, my task may corrupt due to a
- wrong input type. Without language supported RTTI, I have to provide my own
- RTTI to solve this problem. If the system is general purposed and must be
- integrated with the language environment, again, I have to write a precompiler
- to create my own language (example: IDL for remote procedure call)!
-
- And I'm sure many OO database and OS people can tell more.
-
- Since OO technique is aimed mainly to developing large, complex and
- coorperative systems, C++, as general purposed OO language, should at least
- cover some main application areas.
-
- David Shang
-