Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!lad-shrike!milano.sw.mcc.com!cadillac!dsouza From: dsouza@optima.cad.mcc.com (Desmond Dsouza) Newsgroups: comp.std.c++ Subject: Re: type/member tags (was Re: asking an object for its type) Message-ID: Date: 24 Feb 91 23:34:54 GMT References: <65451@brunix.UUCP> <1991Feb19.191731.4137@pa.dec.com> <1991Feb19.214327.13930@gpu.utcs.utoronto.ca> <27C2D973.3C1B@tct.uucp> Sender: news@cadillac.CAD.MCC.COM Organization: MCC CAD Program, Austin, Texas Lines: 88 In-reply-to: chip@tct.uucp's message of 20 Feb 91 20:17:55 GMT This topic does come up quite often, doesn't it? In article <27C2D973.3C1B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > Bzzt. You forgot: > > TODAY.2 virtual member function that does the operation or reports > failure and/or raises an exception. > - uses language features already available > - doesn't require client changes when class hierarchy changes > > >SOL.2 .class member, similar to .this member > if (x.class == circle) && ((circle)x.diameter > 30)) then { > > This solution would require a unique program-wide integer that would > represent each class. (Can you say Objective-C? Ugh.) It would also > impose the space overhead of virtual functions on classes that do not > need it. It would further make programs dependendent on the details > of inheritance. ("Let's see, I want all subclasses of foo except bar, > um, they're larry, moe, curly..." Double ugh.) > This only requires that (x.class) be of type, say, "ClassId", which supports "ClassId == ClassId" for class identity, and possibly "ClassId <= ClassId" for sub-class checks. The user does not need to worry about details of inheritance as this is done by the ClassId type. ClassId could also contain lots of other incredibly useful information in general. ClassId may be implemented as a string encoding the object's class name as well as the class names of all its ancestors, or as one of many possible alternate encodings of hierarchies. It does not require a unique program-wide integer per class. It is reasonable for x.class to be a virtual function call ONLY if class X already has virtual functions (why else would you have a Circle in a list of Shapes?). Otherwise, it could be just a regular member function call. Hence, you do not have to add virtual-ness to otherwise non-virtual classes. > > >It just isn't a controversy, except for Bjarne it seems. At least I > >haven't seen any evidence of someone else saying you should never see > >the type of an object. > > Count me in with Bjarne. You, the programmer, never really want to > know the type. You may think you want to know the type, but why? So > you can know if a feature is available. So make the feature a virtual > function and be done with it. There are a lot of cases where free access to type information would be better replaced with virtual functions, BUT NOT ALL. Here are a few examples where you need to know the type of an object: 1. Persistent objects: When reading in one of these from disk, you need to know what constructor to call. Hence you need to encode in the persistent image the ClassId of the object. 2. You have an interactive system where a mouse-weilding user dynamically configures objects together. You need to check the configuration for validity, which needs many of the same type-relationship checks that the compiler would perform, were it statically analyzing program text which configured the same objects. 3. Almost any application related to a programming environment: debuggers, smart re-compilers, ... > -- > 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) The compiler has access to almost all of this information at compile time. If the above 3 examples reflect a legitimate need, it seems unreasonable for the user to worry about them all over again. Also, C++ cast restrictions on virtual-base classes (cannot cast from virtual base to derived) could be removed if the compiler made some of this information available at run-time! Desmond D'Souza MCC. -- ------------------------------------------------------------------------------- Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza