Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!eagle!icdoc!dcw From: dcw@icdoc.UUCP Newsgroups: comp.lang.c++ Subject: Re: Questions About C++ Message-ID: <457@ivax.doc.ic.ac.uk> Date: Fri, 12-Jun-87 12:41:28 EDT Article-I.D.: ivax.457 Posted: Fri Jun 12 12:41:28 1987 Date-Received: Thu, 18-Jun-87 01:00:57 EDT Sender: dcw@doc.ic.ac.uk Reply-To: dcw@doc.ic.ac.uk (Duncan C White) Distribution: comp Organization: Dept. of Computing, Imperial College, London, UK. Lines: 229 *** WARNING: 300 LINE ARTICLE... HIT j IF YOU'RE NOT INTERESTED... Summary, part 3/3: 'IN', 'QUA' and 'SUPER': We found that several important ----------------------- operators aren't available in C++. a). SUPER Paul Calder said : >It is mildly inconvenient that C++ does not provide COMPILE-TIME access to >a derived class's base class. We have found that there are a number of >situations where a virtual function calls the corresponding function in its >base class .... It would be convenient to specify this as base:: I'm not sure about 'compile-time only'.. but even that would be a help. Jacob Gore Northwestern University, Computer Science Research Lab, [ Chicago? ] sent us a fascinating letter about Objective-C. He says: >From my experience, 'super' is very useful. Most often, it is used to envoke >the 'default action', as specified by the superclass, after performing the >action specific to this class. A method 'doSomething' in class C may perform >some action, and then call the method 'doSomething' in its superclass. Of >course, if the superclass' name is known, it can be used in place of 'super', >but (a) the specific name is not always known, (b) using the specific name >hinders reusability, and (c) using 'super' all the time is more convenient, as >well as more obvious. Jonathan Shopiro, AT&T Bell Labs, however, suggested that super was unnecessary, saying: >... just as you almost never have >to determine the class of an object in Smalltalk, you never need it in >C++ either. To summarise, most people felt the need for some form of 'super', although this was not unamimous. b). QUA Thomas Maslen suggested: >Type-casting can be used for the "treat it as an X" part of qua. Note, however, that SIMULA would give a compile-time error if the instance belongs to an entirely different hierarchy, whereas C++ will let it straight through. David Wonnacott also suggested type-casting, giving the example: >vehicle *vp = new car; > > ((car *) vp) -> wheels(); > And continued with: >Note that, when you put in an explicit type cast, NO type checking is done. >It is therefore up to the programmer to remember that vp does, in fact, point >to a car.. If vp pointed to a boat (no function called wheels()), strange >things (not an error) would happen at run time. This is an important point: in both languages, it is up to the programmer to ensure that a vehicle-instance is actually a car before applying QUA [or type casts]. However, at least SIMULA will give an immediate run-time error, whereas C++ will carry on regardless... c). IN Bjarne Stroustrup suggested : >A piece of advice: If you can avoid it, don't even simulate IN. Most >often you don't need it. I consider INSPECT and QUA efficiency hacks >in Simula. In C++ you can most often dispense with them in favor of >using virtual functions. >If you must, and in general, you access a member of a base class >(immediate or not) by prefixing the member name by its class name: David Wonnacott says, of the IN operator: >C++ does not provide any facility for this, as it would involve a >storage overhead. As I understand it, the only place where C++ adds any >storage or run-time calculation is with virtual functions. > >There are, however, many times when you would like to find out what class >an object is, or determine whether it is derived from a given class. This >can be accomplished by creating a base class (traditionally called "object"), >and deriving all other classes from it. class object an then have member >functions equivalent to "in". Writing such a class is pretty hard, and I >suggest that you look around for a public domain C++ library that provides >such facilities (I know one exists, you might try asking on the net). I'm very interested in such a PD C++ library... any comment, anyone ?? Several people suggested ways of implementing a restricted, 'IMMEDIATE IN' which we will call 'isa' : Andrew Koenig made an excellent suggestion: >So far, we have had to rely on our own devices to determine what >kind of individual is designated by an employee pointer. We would >really like the implementation to keep track of that for us. For >example, we might like to have a string called, say "title" that >represents the rank of the employee. > > class employee: { > virtual char* title() { return "employee"; } > // other stuff > }; > > class manager: employee { > char* title() { return "manager"; } > // other stuff > }; > >... ditto for director > >... Now, if we have an employee pointer ep, we can say: > > printf ("%s\n", ep->title()); > >and it will print the the actual employee title. Andrew's scheme works very nicely: add to employee the following function: [not virtual, not overloaded: ONLY in employee] boolean isa( char *p ) { return strcmp( this->title(), p ) == 0; } and then all subclasses of employee can use it. Some examples: void test( char *s, boolean b ) { cout << s << ": " << ( b?"true\n":"false\n" ) ; } employee e; employee *eptr = new manager; manager *mptr = new manager; test( "e isa employee" , e.isa("employee") ); test( "e isa manager" , e.isa("manager") ); test( "eptr isa employee", eptr->isa("employee") ); test( "eptr isa manager:", eptr->isa("manager") ); test( "mptr isa employee", mptr->isa("employee") ); test( "mptr isa manager" , mptr->isa("manager") ); .... and many other similar tests one can think of.. Paul Calder suggested a similar scheme. Jacob Gore says that Objective-C provides: > [x isMemberOf: C] iff x is an instance of class C > [x isKindOf: C] iff x is an instance of C' and C' is a subclass of C > (also, if [x isMemberOf: C] then [x isKindOf: C]). From this description, isMemberOf is 'isa' and isKindOf is 'in'. It sounds like Objective-C has more run-time support than C++ [comments welcome] It sounds like a nice language: where can we get it, anyone ? CONCLUSION: ---------- I think the best summary comes from David Wonnacott : >without the ability of the compiler to use a derived class pointer >when a base class pointer is needed, or to use a derived class object to >initialize a base class reference, C++ would indeed provide very weak >object - oriented facilities. It does lack important functions like "in" >and "super", but they incur a storage and time overhead, so they are left >for the user to implement where needed. They are extremely hard to implement >(as you learned whey you tried), so you should look for a library that >provides them. Bjarne Stroustrup commented, of direct relevance to our requirement for C++ : >Are you aware of the task library as a C++ alternative to the >Simula class SIMULATION? Susan Coatney elaborated : >[the task library] is a package developed for discrete-event simulation >utilizing co-routine style multitasking. We weren't aware of the task library: the only information we had about C++ was the Book itself. Obviously, it is not the authorative source we had hoped (semi :-) We will obviously have to seek out whatever documentation came with the C++ sources [ we are running 1.1, and have 1.2 awaiting installation - I tried to install it on SUN 3/50s and BSD4.3, but failed miserably ] Bjarne's final suggestion was: >Have you seen my overview of C++ in SIGPLAN Notices Oct'86. Many people >find it a better introduction to the concepts in C++ than the book >itself. Now we know about it, we will certainly look it up. Finally, we are very interested in any further [private or public] communication about the suitability of C++ for simulation. Thanks to everyone who responded for all the help... our apologies for the obvious boo-boo. -- Duncan White & Phil Hands. ----------------------------------------------------------------------------- JANET address : dcw@uk.ac.ic.doc| Snail Mail : Duncan White, --------------------------------| Dept of Computing, This space intentionally | Imperial College, left blank...... | 180 Queen's Gate, (paradoxical excerpt from | South Kensington, IBM manuals) | London SW7 ---------------------------------------------------------------------------- Tel: UK 01-589-5111 x 4982/4991 ----------------------------------------------------------------------------