🚀 go-pugleaf

I work on an application that has objects that know their type
(implementation based on the NIHCL approach). This application also
has many classes which do not have type information. I see this as an
expression of the flexibility of C++--if you need type information,
you can program it, otherwise you're not burdened with its overhead.

However my attitude about this is not inflexible. I believe it would
make sense to include type related functions for classes which have
virtual functions as a standard part of the language. Overhead could
be restricted to a per class basis, rather than a per object basis.
Certain limitations, such as casting down from a virtual base class,
could then be overcome. Compatibility with C would not be affected.
Compatibility with existing code would be minimally affected. I
believe that the need for this sort of information on objects that
have virtual functions is pervasive enough to warrant this minimal
overhead. I believe that compiler supported implementations could be
substantially better than user programmed implementations. While I
don't have any good suggestions for how this might be supported
syntactically, I believe that a reasonable solution can be found.

In short, I believe that it makes sense to recognize "classes with
virtual functions" as an important concept worthy of a name and
special functionality.
--

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
----------------------------------------------------------------------------------
I spent from $3 to $10 today to pay interest on the national debt.  How about you?
----------------------------------------------------------------------------------