home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++,comp.strd.c++
- Path: sparky!uunet!mole-end!mat
- From: mat@uunet.uu.net!mole-end
- Subject: Re: Language extensions for run-time type identification
- Message-ID: <1992Jul26.025147.6278@uunet.uu.net!mole-end>
- Organization: :
- References: <1992Jul24.070325.1597@uunet.uu.net!mole-end> <1992Jul24.145147.19761@cadsun.corp.mot.com>
- Date: Sun, 26 Jul 1992 02:51:47 GMT
- Lines: 29
-
- In article <1992Jul24.145147.19761@cadsun.corp.mot.com>, shang@corp.mot.com (David (Lujun) Shang) writes:
- > In article <1992Jul24.070325.1597@uunet.uu.net!mole-end>
-
- > > And not to make you too happy: comparing vtable pointers could only be
- > > a first step unless you are absolutely sure that the compilation and
- > > linking system will never duplicate a vtable. This is a hard assumption
- > > to prove, especially with dynamic linking of new types.
-
- > The compiler and linker should essure that the vtable for a particular
- > class is unique.
-
- Yes, well, we may have to solve those problems to do templates well ...
- but for right now we are stuck with existing linkers.
-
- > Anyway, after a sencond thought, I still insist on my original opinion, that
- > is, it is not a good idea to use vtable pointer as the type-id. Vtable
- > pointer is environment-dependent, it cannot serve as a type identifier
- > to communicate between two defferent environments.
-
- Pointer comparison is an optimization; in a single memory space it's
- worth trying ... but you are right; deep equality comparison is needed.
- All the problems that arise (including source file identification for
- static types--and THAT includes directory structure) get worse when you
- do cross-environment stuff.
- --
- (This man's opinions are his own.)
- From mole-end Mark Terribile
-
- uunet!mole-end!mat, Somewhere in Matawan, NJ
-