Re: references and const pointers optimization

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Fri, 23 Nov 2007 10:36:58 -0600

Message-ID:

<697269ED-9C22-4FC5-80B5-20738C116615@microsoft.com>

"Stuart Redmann" <DerTopper@web.de> wrote in message
news:fi6css$13a$1@news.dtag.de...

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):

And also not to be confused with pointer-to-member (thankfully there is no
"reference-to-member").

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