Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!stiatl!srchtec!johnb From: johnb@srchtec.UUCP (John Baldwin) Newsgroups: comp.lang.c++ Subject: Re: Efficient compilation of virtual functions Message-ID: <195@srchtec.UUCP> Date: 7 Sep 90 00:25:33 GMT References: <6428@wolfen.cc.uow.oz> <7&`%1J-@rpi.edu> Organization: search technology, inc. Lines: 37 In article <7&`%1J-@rpi.edu> adamsf@turing.cs.rpi.edu (Frank Adams) writes: [referring to how to inform the compiler something is at the end of the inheritance tree]... > >Another approach would be to allow "exact" or "non-virtual" pointers. Then > >foo exact * p1; >foo * p2; > >would declare p1 a pointer specifically to a foo, while p2 would point to >an instance of foo or one of its subclasses. Exact pointers can be converted >freely to ordinary pointers to the class (and thence to superclasses), but >the reverse conversion should require a type-cast. This seems like a very appropriate addition to C++. It is a lot like other "type modifiers" (const, etc.) and has a very "C++ -ish flavor" to it. That is, it can both be used to inform the compiler of cases where additional optimizations may be performed, and it also has the effect of allowing a greater degree of control over the code. I would view the "exact" modifier as an additional control-of-scope, especially if it could be applied to member functions in the same way that "virtual" is. I'm not sure it would be a good idea to allow both directions of conversion as mentioned above by Mr. Adams. To me, "exact" is of a constraining nature, like "const." It's generally not considered to be a good idea to be able to cast a const-something to a non-const-something and then change it. :-) Where else could the hypothetical keyword "exact" be used to good effect? -- John T. Baldwin | johnb%srchtec.uucp@mathcs.emory.edu Search Technology, Inc. | | "... I had an infinite loop, My opinions; not my employers'. | but it was only for a little while..."