Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (              Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: const, reference "this" revisited ???
Message-ID: <6590018@hplsla.HP.COM>
Date: 19 Feb 88 06:18:01 GMT
References: <6590014@hplsla.HP.COM>
Organization: HP Lake Stevens, WA
Lines: 32

| I don't think that there is an efficiency issue (that is, there may
| be an issue over the efficiency of a given implementation - cfront
| output is only as efficient as the equivalent C, it could be more
| efficient - but there is no need for new language features to support
| even further speedups).

Well, my original comments were made in regard to ultimate 68020 code
I've seen generated from C++ routines that do something like this

aClasss::vfunction()
{
    this->vfunc1();
    this->vfunc2();
    this->vfunc3();
}

and the ultimate code generated by the various combinations of cfront, cc
gcc and g++ all seem to end up with the same problem, namely that "this"
and "this->vtable" are being reloaded into register every time after a vfuncX()
is called.  And given that *this could be overridden in any of the vFuncX()
what other code could a compiler generate? -- unless you have a compiler that
generates metacode which is not turned into actual machine code during
the link process?  And even then I have a hard time imagining that the
optimization process is really going to discover whether or not *this gets
clobbered in a given vFuncX();

So my only thought was if there was someway to state a given vfuncX() DOES
NOT clobber *this then this and this->vtable would only have to be loaded
into registers once at the start of vfunction, and thereafter calling a 
vfuncX() would only entail an indirect-with-offset function call.

Seems like an efficiency issue to me.