Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!radar!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: 26 Feb 91 19:03:43 GMT References: <1991Feb19.214327.13930@gpu.utcs.utoronto.ca> <27C2D973.3C1B@tct.uucp> <27C95D3A.1715@tct.uucp> Sender: news@cadillac.CAD.MCC.COM Organization: MCC CAD Program, Austin, Texas Lines: 96 In-reply-to: chip@tct.uucp's message of 25 Feb 91 18:53:46 GMT In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >Here are a few examples where you need to know the type of an object: > > "Need?" That's a red flag for me... :-) It is a red flag for me too. And lots of red flags mean it is quite possibly a legitimate shortcoming. > >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. > > Presumably, a well-designed class hierarchy will use a virtual > function to store objects; and a virtual function by definition will > already know the exact type of the object it is storing. Yes, but it needs to make it _explicitly_ available in the binary image. Retrieving and re-constructing persistent objects is where you *need* explicit type information. Virtual functions dont help now because you do not have an existing object to dispatch off. 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. Ditto for transferring objects across address spaces, networks, etc. > >2. You have an interactive system where a mouse-wielding user > > dynamically configures objects together. You need to check the > > configuration for validity ... > > ClassID would be a useful tool in such code, but it is by no means > necessary. For example, each class can have virtual functions along > the lines of "int can_be_owned()". And do you want J. Random Coder > making decisions like "if x is a Widget, but not a FooWidget..." 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? Why not offer the type checking facility and teach J. Random Coder when _not_ to use it ? > >3. Almost any application related to a programming environment: > > debuggers, smart re-compilers, ... > > I can see it for debugging. But the extra cost of the feature is not > something I'd want to inherit permanently in my delivered executable. > And I must say that debugging alone is a little thin as justification > for a language feature with run-time costs. The cost, as you admitted, can be quite manageable. The primary problem, as Stroustrup points out, is pick an acceptable amount of functionality for 'ClassId'. Check out some papers on "reflection" in languages to see just how powerful classes-as-objects _can_ be. In fact, persistence, dynamic configuration and debugging can be all viewed as "reflective" capabilities. 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"); Any implementation of this involves a run-time type check, including class derivation, on the object being thrown. Can you say 'Meta-class'? Most static class variables and static class functions (explicit or implicit) can be considered members of a corresponding class object. > >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! > > 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. > Chip Salzenberg at Teltronics/TCT , Desmond. -- ------------------------------------------------------------------------------- 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