Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <6590121@hplsla.HP.COM>
Date: 11 May 89 17:54:21 GMT
References: <904@garya.Solbourne.COM>
Organization: HP Lake Stevens, WA
Lines: 90

> In article <6590119@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
> >
> >I have no problem with C++ *the language*, it *can* be efficiently
> >implemented on today's machine -- I just haven't yet seen a C++
> >compiler that *does* implement major details of the language efficiently.
> 
> This was not at all clear from your earlier remarks (at least not to
> me.)  My earlier notes were addressing language design issues, not
> optimization issues.  

I'm a language user, not a designer.  Either give me the constructs I need
to use the language efficiently, or make compilers smart enough to 
optimize out excess generality where it's not needed.  Allowing access
to members [at least statics] through the vtable would be one step in
the right direction.  Or having a compiler smart enough to inline
virtual functions where one could reasonably expect to see inlined
virtual functions would be another step in the right direction.

Personally, I believe that it is better if most of these smarts are
in the compiler.  Compilers that figure out what to register, for 
example, rather than having to specify what a user wants to "register",
is an old example from the "C" world.

> Complaints about the quality of optimizations
> of compilers ought to specify what compiler you're complaining about.

I agree Jerry.  And as I've complained to you before, I ought to be able
to discuss these things freely [like what compiler I'm using]
-- especially since people at AT&T are discussing these things freely.  
But agreements between AT&T and HP prevent me from discussing these 
things freely -- I've gotten my hands slapped before.  
And then *you* complain about my inability
to discuss these things freely.  I think that is unfair.  If AT&T
people are free to discuss these things, then so should I be.  How
about calling off your lawyers, so that we can discuss these things
publicly?

> >The biggest disappointment so far is unnecessary expansion of
> >inline virtual functions into table lookup + indirect function calls.
> 
> You may be happy to learn that the pre-release 2.0 does expand
> virtual functions inline when it can determine the correct version.
> 
> 	struct K { 	
> 		virtual int size() { return sizeof(K) ; } ;
> 	} ;
> 
> 	void g() {
> 		K k ;
> 		int s = k.f() ; 
> 			// this is expanded into a simple
> 			// assignment in sizeof(struct K)
> 	}
> 

Okay, so perhaps you can tell us whether the release version of 2.0
will be able to inline in the following almost-as-trivial situation:

class K 
{     
public:
    virtual int size() { return sizeof(K) ; } ;
} ;

class L 
{     
int stuff;
public:
    virtual int size() { return sizeof(L) ; } ;
} ;

void g() {
    K k;
    L l;
    int s = k.size() ; 
        // is this example expanded into a simple
        // assignment in sizeof(struct K) ???
	// Why, or Why Not ???
}

Please test this example before you answer.

When 2.0 does comes out, how are people going to know what it can,
or can't do?  Are some of these important issues going to be
openly addressed?  Can we get a list of what new features are,
or are not going to be in 2.0?  Can we get a list of limitations
on 2.0 -- where or where not will it be smart enough to inline,
for example?

Or are customers expected to buy a pig in a poke?