Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!husc6!ngo From: ngo@tammy.harvard.edu (Tom Ngo) Newsgroups: comp.std.c++ Subject: Responses to ~const 1.6: Possible generalizations of ~const Message-ID: Date: 19 Feb 91 16:40:34 GMT Sender: news@husc6.harvard.edu Distribution: comp Organization: Harvard Chemistry Department Lines: 94 Background information to this posting was in a very recent summary. Having a ~const specifier suggests four other specifiers: ~volatile ~register ~inline ~virtual Jim Adcock suggested the last three and gave the following proposed definitions for all four: ~volatile Do allow optimization on this object [even if the enclosing object is declared volatile]. ~register Do not enregister this object, even when optimizing. ~inline Do make this method a real function call. ~virtual Do not put this method in the vtable [even if a function of exactly the same type was declared virtual in a base class]. Joe Buck was against ~volatile on the grounds that it would add virtually nothing to the language; it would "give a tiny bit of useful information to an optimizing compiler, [but] it would gain nothing in expressive capability." Joe Buck and Ron Guilmette felt that symmetry and simplicity of implementation might be good reasons to permit a ~volatile specifier. Jim Adcock seemed to feel the most strongly about ~inline, which would give an simple way to debug inline functions without having to disable inlining for a whole program. The mention of ~inline sparked a separate debate about compiler hints which I will not summarize. Before I give my reactions, let me say that these specifiers will probably get only a mention in my proposal to the ANSI committee. I think they are sufficiently different from ~const that they should be treated separately, and I have no plans to write up proposals for them. (Any takers?) Having said that, * I agree that ~volatile would be just about useless, but that for the sake of symmetry and simplicity it might be worth throwing in. * The existing keywords "inline" and "register" interact little with other specifications. In particular, they affect neither the behavior of a program nor the validity of the rest of the code. This is by necessity, because according to the ARM they are only hints: the programmer cannot know before compile time whether the hints will actually be taken. * The proposed phrases ~inline and ~register should mean exactly the opposite of inline and register, except that ~inline should not be a mere hint. It would be used primarily to permit source-level debugging of a particular function without having to recompile a whole program without inlining. If you write ~inline, you will want to be certain that your function will actually be implemented as a function call! * ~virtual is the one I am least convinced about. Clearly it does nothing to a method which is not already in the vtable of any base class. So we are left with the following semantics. Following ARM 10.2, If a class "base" contains a virtual function vf(), and a class "derived" derived from it also contains a function vf of the same type, then a call of vf for an object of class "derived" invokes derived::vf() (even if the access is through a pointer or reference to "base"). The derived class function is said to override the base class function.... ...the interpretation of the call of a virtual function depends on the type of the object for which it is called, whereas the interpretation of a call of a nonvirtual member function depends only on the type of the pointer or reference denoting that object.... ...An overriding function is itself considered virtual UNLESS it is declared ~virtual. I am uncomfortable with the fact that someone writing a function that takes pointers to "base" cannot know whether calls to vf() are really virtual for all derived classes, without looking at all of their declarations. I am still interested in hearing about potential uses for ~virtual. -- Tom Ngo ngo@harvard.harvard.edu 617/495-1768 lab number, leave message