Path: utzoo!attcan!uunet!seismo!dimacs.rutgers.edu!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: <27CC322C.510C@tct.uucp> Date: 27 Feb 91 22:26:51 GMT References: <27C95D3A.1715@tct.uucp> Organization: Teltronics/TCT, Sarasota, FL Lines: 62 According to dsouza@optima.cad.mcc.com (Desmond Dsouza): >Retrieving and re-constructing persistent objects is where you *need* >explicit type information. Virtual functions dont help now ... Of course they don't help; but explicit type information doesn't help, either. The language type system is inoperative when dealing with objects that have been "frozen" into dead arrays of bytes. >Storing objects is relatively easy, e.g. with a virtual function which >writes out some ClassId information. Hence, your objects must have a >way to access (and write out) their true type. When a virtual function is invoked, the type is implied, unless the programmer has made the mistake of allowing a virtual function to be inherited by a derived class that should be frozen in a distinct way from its parent. >Solutions like "virtual int can_be_owned()" are an incredible >implementation overhead when you are dealing with combinations of >object classes and relationships between them. > >e.g. Can an A be plugged into a B in the slot x ? How about an A1 into >slot z of a B1? The problem as described is inherently complex. The complexity of a solution is neither created nor worsened by a solution of the can_be_owned() type. >Why not offer the type checking facility and teach J. Random Coder >when _not_ to use it ? I agree with this approach. After all, if I opposed features purely on the basis of possible misuse, then I wouldn't be using C++. :-) So in the end, my opposition isn't to the feature, but to the attitude manifested by some that it's practically necessary for OOP. It's not. ``isKindOf is the OOP equivalent of goto.'' --me >Consider the proposed (now accepted) Exception Handling scheme for >C++. The statement: > catch (ErrorClass& o) { > .... > } >is supposed to 'catch' a deeply nested call to: > throw ErrorClass("someError"); Unless I misunderstand the implementation issues, name equivalence can solve this problem without resorting to dynamic type information, and also without incurring run-time overhead that dynamic type checking would likely impose. > > But you can always write a virtual function that does the cast. > >True. It is painful, error-prone, and the compiler can do a much better job. My experience is not so negative, though I grant that I'd prefer the compiler to more of my work. (Always!) -- Chip Salzenberg at Teltronics/TCT , "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)