Re: references and const pointers optimization
qfel wrote:
int ov,&ref=ov;
I thought that treating ref as an alias to ov should be ok, but seems
with full optimization turned on (VC2k8, /Ob2 /Oi /Ot /Oy /GL) assigning
1 to ref still produces code like
mov ecx, DWORD PTR _ref$[ebp]
mov DWORD PTR [ecx], 1
vs
mov DWORD PTR _ov$[ebp], 1
produced by directly assigning to ov.
While it's not a big deal most of the time, isn't it quite surprising
that simple optimization isn't performed? Sometimes I want to have a
shorter name for struct member and wasting memory just for that feels a
bit uneasy. Or maybe should I use some magic __declspec / other options?
If you want to use __declspec, you're talking about member references. Note that
the compiler must always use pointer implementation for member references, as it
cannot predict which member the member reference should be tied to until the
constructor is run (as opposed to plain references inside functions):
void function ()
{
int x;
// Compiler knows that ref_x is always bound to x, so it
// can implement ref_x by symbol table alias.
int& ref_x = x;
}
struct Struct
{
// Constructor that ties m_ref to m_x.
Struct () : m_ref (m_x) {}
// Another constructor that ties m_ref to m_y.
Struct (int) : m_ref (m_y) {}
int m_x;
int m_y;
// Compiler doesn't know which member m_ref should be tied to.
// Thus it can only use pointer implementation for reference.
int& m_ref;
}
I use the __declspec magic at some places in my code. I know that this makes my
code non-portable, but when push comes to shove I can change the member access
to accessor method calls throughout the project (which I should have done in the
first place).
Regards,
Stuart