Re: Does binding to const-reference outperform copy-initialization from returned value?
const Foo& constReference = GetFoo();
const Foo constValue = GetFoo();
constReference.VirtualFunc();
constValue.VirtualFunc();
When calling the virtual function on the reference, I guess it will
use the VTable, while it won't do so on the copy-initialized value.
Igor Tandetnik wrote:
Not necessarily. It is clear that constReference can only be bound to an
instance of Foo here, and not any derived class. Optimizer could figure
this out and generate a direct (non-virtual) call. I don't know if it's
smart enough though, and I'm too lazy to test.
I just looked into the ASM output (compiled as "Release"). When VC++ 2008
SP1 compiles the following test as "Release", the compiler inlines
constValue.VirtualFunc(), but it doesn't inline
constReference.VirtualFunc(). Unfortunately...
////////////////////////////////////////
class Foo
{
unsigned memberData;
public:
virtual int VirtualFunc() const;
};
int Foo::VirtualFunc() const
{
return 42;
}
Foo GetFoo()
{
return Foo();
}
int main(int, char**)
{
const Foo& constReference = GetFoo();
const Foo constValue = GetFoo();
int result1 = constReference.VirtualFunc();
int result2 = constValue.VirtualFunc();
return result1 + result2;
}
////////////////////////////////////////
As shown by the ASM output:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; 222 : const Foo& constReference = GetFoo();
; 223 : const Foo constValue = GetFoo();
; 224 : int result1 = constReference.VirtualFunc();
lea ecx, DWORD PTR _$S1$[esp+8]
mov DWORD PTR _$S1$[esp+8], OFFSET ??_7Foo@@6B@
call DWORD PTR ??_7Foo@@6B@
; 225 : int result2 = constValue.VirtualFunc();
; 226 : return result1 + result2;
add eax, 42 ; 0000002a
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
BTW, when I put a breakpoint inside VirtualFunc(), the debugger does indeed
get there, even in a Release build. In Debug mode, it gets there twice (for
both constReference and constValue), in Release mode, it gets there once
(only for constReference).
I guess there's an opportunity for further improvement of the optimizer of
Visual C++, right?
Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center