Re: private inheritance vs containment
On 5/29/07 4:49 PM, in article f3i6uv$pmu$1@mouse.otenet.gr, "Sam"
<sakarab@yahoo.com> wrote:
Daniel T. wrote:
In article <f3erhm$fnq$1@mouse.otenet.gr>, Sam <sakarab@yahoo.com>
wrote:
When a contained object member function is called, its "this" pointer
must be calculated and passed to it. On the other hand in an inheritance
relationship the "this" pointer is the same with the derived object. No
calculation needed.
The above is a micro-optimization that the compiler can likely take care
of itself.
Our perspective differ. You call it "micro-optimization", I call it "(small)
extra performance", others are concerned about the overhead of a virtual call
and others don't (virtual call's overhead compared to the containment overhead
is almost the same, fetch one extra address, the address of a function in the
first case, the address of the this pointer of the contained object in the
later).
There is no "extra performance" obtained by using private inheritance
instead of containment in the example below - because the
"computational work" required by the semantics of either approach is
the same. In both cases, two methods are called and each is passed a
"this" pointer (at least conceptually) as a hidden argument. Since
neither of the "this" pointer arguments so passed is any more
expensive for the compiler to obtain than the other - and since
obtaining neither pointer requires any additional runtime information
over and above what is needed to obtain the other pointer - there is
no basis for concluding that private inheritance offers any
performance advantage (however minuscule) over containment.
In particular, any comparison between containment and virtual method
dispatching is simply erroneous. The compiler does not need b's
address in order to obtain b.mA's address. Because b.mA is located at
a known location within a B object (which in the code below happens to
be zero), the compiler can just as easily pass mA as a "this" pointer
argument as it can a pointer to b itself.
And real-world C++ compilers bear this observation out: on a typical
machine architecture, local variables are referenced as offsets
relative to a stack pointer. So, for example, if b is located at
0(SP), then mA would also be found at 0(SP) (in the example below) -
but even if mA were located 4(SP) or 8(SP) or wherever - there would
be no additional overhead incurred: instead of passing 0(SP) to each
of the two methods, the compiler would pass 0(SP) to the first method
and 4(SP) to the second and do so no less efficiently.
Example:
struct A
{
void do_work();
};
// containment
class B
{
private:
A mA;
public:
void do_work() { mA.do_work(); }
}
// private inheritance
class C : private A
{
public:
void do_work() { A::do_work(); }
}
int main()
{
B b;
// gets address of b, calculates address of
// B::mA and calls A::do_work()
b.do_work();
C c;
// gets address of c, directlly calls A::do_work()
c.do_work();
}
In the above code, the B::do_work function would likely be expanded
inline which means the "calculation" you speak of is done at compile
time, not run time. No performance advantage here.
There are cases where the compiler can optimize the "calculation" / passing of
the this pointer, if for example
1. the address of the container object is the same with the contained object
2. the code of the A::do_work() function is known to the compiler not to use
any class member variables or methods so it doesn't need a this pointer
3. the called functions is known to access only class member variables that
can be calculated as offset from the address of the container object.
The above list of course is not exhaustive and is implementation dependent.
But private inheritance is not (implementation dependent).
Compiled code is always "implementation-dependent." Eliminating a
second load instruction to pass the "this" argument to the second
method is just as much an optimization as optimizations #1-3 on the
list above. So when comparing the efficiencies of alternate
approaches, it only makes sense to assume an optimally efficient C++
compiler. Otherwise, if one is going to assume that the C++ compiler
does not produce optimally efficient code - then one cannot also
assume that the inefficiencies of the compiler-generated code (and
likewise, whatever optimizations the compiler did apply) will only
favor private inheritance. Yet that is exactly the argument that is
being made here: that the compiler will be smart enough to optimize
away a second load instruction for a this pointer argument when
calling the second method - but at the same time the compiler cannot
be smart enough to eliminate the load instructions completely because
they are not being used at all.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]