Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!taumet!mike
From: mike@taumet.COM (Michael S. Ball)
Newsgroups: comp.lang.c++
Subject: Re: virtual static data?
Message-ID: <232@taumet.COM>
Date: 31 May 90 16:25:23 GMT
Article-I.D.: taumet.232
References: <1990May23.102905.8689@athena.mit.edu> <13757@csli.Stanford.EDU> <54856@microsoft.UUCP> <1990May25.003734.24552@athena.mit.edu> <54945@microsoft.UUCP>
Reply-To: mike@taumet.UUCP (Michael S. Ball)
Organization: Taumetric Corporation, San Diego
Lines: 59

In article <54945@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>The only thing forcing you to use function calls to retrieve a piece of data
>is the fact that present day C++ compilers are not yet up to the level of
>quality required to really support object oriented programming.  People are
>still trying to use C optimization techniques in C++ compilers -- 
>the optimization issues are just not the same.

Actually, the real limitation is the very stupid environments in which
C++ program development takes place.  I mean that the environments lack
built-in intelligence, not that they are stupidly defined.  They worked
fine for developing C.  We seriously looked at a number of optimizations
for our C++ frontend, and had to give them up because the logistics became
unmanagable in most of the environments our customers wanted.

>If other OOPL compilers are smart enough to optimize "foo" to mean either
>a variable look-up or a function call depending on the circumstances, why
>cannot C++ compilers be smart enough to optimize "foo()" to be either a
>variable look-up or a function call depending on the circumstances?
>[whether or not foo is virtual]

Only because it requires more global data than is available in most programming
environments.  On the other hand, even virtual function calls can be
very cheap if properly implemented.

>-- Clearly they can!  They just don't, yet.  One hang up is the notion that
>virtual-ness needs to be handled via vtables.  It needn't.

No, but it's an effecient implementation which requires no global knowledge.

>							     Another hang-
>up is the traditional Unix/C model of separate compilation/linking.  Without
>knowledge of what your children might be doing, its hard [not impossible]
>to avoid doing a full blown virtual function dispatch when only a "virtual
>static member" is needed.

In a true polymorphic situation it can't be avoided without SOME knowledge
of what your children are doing.  In many situations the true type can be
computed at compile time, and you should expect a compiler to do this.  With
enough global knowledge you can specialize routine calls and generate inline
code even with virtual functions.  By the way, a "full blown virtual function
dispatch" isn't necessarily expensive, it just gets that way when you have
to go through C.

>Let's continue to use function syntax for all public interfaces -- even
>though I agree it would have been nice if C hadn't already forced this
>convention.  Let's not continue to add obscure syntax to help mediocre
>compilers optimize uncommon code slightly.

AMEN!

Please note, I support the development of environments which would let
a C++ system do a good job, but I think that a great deal of C++'s
success is due to it's ability to fit into C environments with a minimum
of fuss.  Big environments are expensive to develop and move, so will
only come into existance when the demand justifies it.  C++ is starting
to get there, but isn't yet.

Mike Ball			mike@taumet.com
TauMetric Corporation