Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: <27D270A7.2E3B@tct.uucp> Date: 4 Mar 91 16:07:02 GMT References: <27C95D3A.1715@tct.uucp> <4201@lupine.NCD.COM> Organization: Teltronics/TCT, Sarasota, FL Lines: 29 According to rfg@NCD.COM (Ron Guilmette): >... retrieving (or receiving) an hunk of data which represents the >previous contents of some unknown type of thing requires us to use >some sort of agreed upon scheme whereby the transmitter sends some >unique code with the data block to indicate to the receiver what >type of C++ object the transmitted data came from. In my mind, the only reasonable choice for such a unique code is the class name itself. The C++ language depends on name equivalence, so user code may also depend on name equivalence without problems. >The [messaging] kernel then had to do a lookup of the class name string >within a table of all class-name string known to the system in order to >get a globally unique 32-bit integer valued "code" for that particular >class type. Why not use the class name itself? >A much cleaner solution would have been to enlist the compiler & linker >to assign the globally unique "type codes" up front, prior to run-time. >This would have allowed us to avoid the (very expensive) table lookups >which we did within the kernel for each transmitted message. A string lookup though a set of strings fixed at compile time needs to be rewritten if it is "very expensive." -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre