🚀 go-pugleaf

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 <jimad@microsoft.UUCP> 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 <jbuck@galileo.berkeley.edu> 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 <rfg@ncd.com> 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