const reference public member to private class member - why does it work?

Question

Recently, I found an interesting discussion on how to allow read-only access to private members without obfuscating the design with multiple getters, and one of the suggestions was to do it this way:

#include <iostream>

class A {
public:
  A() : _ro_val(_val) {}
  void doSomething(int some_val) {
    _val = 10*some_val;
  }
  const int& _ro_val;
private:
  int _val;
};

int main() {
  A a_instance;
  std::cout << a_instance._ro_val << std::endl;
  a_instance.doSomething(13);
  std::cout << a_instance._ro_val << std::endl;
}

Output:

$ ./a.out 
0
130

GotW#66 clearly states that object's lifetime starts

when its constructor completes successfully and returns normally. That is, control reaches the end of the constructor body or an earlier return statement.

If so, we have no guarantee that the _val memeber will have been properly created by the time we execute _ro_val(_val). So how come the above code works? Is it undefined behaviour? Or are primitive types granted some exception to the object's lifetime?

Can anyone point me to some reference which would explain those things?

Answer 1

Before the constructor is called an appropriate amount of memory is reserved for the object on Freestore(if you use new) or on stack if you create object on local storage. This implies that the memory for _val is already allocated by the time you refer it in Member initializer list, Only that this memory is not properly initialized as of yet.

_ro_val(_val)

Makes the reference member _ro_val refer to the memory allocated for _val, which might actually contain anything at this point of time.

There is still an Undefined Behavior in your program because, You should explicitly initialize _val to 0(or some value,you choose)in the constructor body/Member Initializer List.The output 0 in this case is just because you are lucky it might give you some other values since _val is left unInitialized. See the behavior here on gcc 4.3.4 which demonstrates the UB.

But as for the Question, Yes indeed the behavior is Well-Defined.

Answer 2

The object's address does not change.

I.e. it's well-defined.

However, the technique shown is just premature optimization. You don't save programmers' time. And with modern compiler you don't save execution time or machine code size. But you do make the objects un-assignable.

Answer 3

In my opinion, it is legal (well-defined) to initialize a reference with an uninitialized object. That is legal but standard (well, the latest C++11 draft, paragraph 8.5.3.3) recommends using a valid (fully constructed) object as an initializer:

A reference shall be initialized to refer to a valid object or function.

The next sentence from the same paragraph throws a bit more light at the reference creation:

[Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior.]

I understand that reference creation means binding reference to an object obtained by dereferencing its pointer and that probably explains that the minimal prerequisite for initialization of reference of type T& is having an address of the portion of the memory reserved for the object of type T (reserved, but not yet initialized).

Accessing uninitialized object through its reference can be dangerous.

I wrote a simple test application that demonstrates reference initialization with uninitialized object and consequences of accessing that object through it:

class C
{   
public: 
    int _n;

    C() : _n(123)
    { 
        std::cout << "C::C(): _n = " << _n << " ...and blowing up now!" << std::endl;       
        throw 1;
    }
};

class B
{
public: 

    // pC1- address of the reference is the address of the object it refers
    // pC2- address of the object
    B(const C* pC1, const C* pC2)
    {
        std::cout << "B::B(): &_ro_c = " << pC1 << "\n\t&_c = " << pC2 << "\n\t&_ro_c->_n = " << pC1->_n << "\n\t&_c->_n = " << pC2->_n << std::endl; 
    }
};

class A
{
    const C& _ro_c;    
    B _b;
    C _c;

public:     

    // Initializer list: members are initialized in the order how they are 
    // declared in class
    //
    // Initializes reference to _c
    //
    // Fully constructs object _b; its c-tor accesses uninitialized object 
    // _c through its reference and its pointer (valid but dangerous!)
    //
    // construction of _c fails!
    A() : _ro_c(_c), _b(&_ro_c, &_c), _c()
    {
        // never executed 
        std::cout << "A::A()" << std::endl;
    }
};

int main()
{
    try
    {
        A a;
    }
    catch(...)
    {
        std::cout << "Failed to create object of type A" << std::endl;
    }

    return 0;
}

Output:

B::B(): &_ro_c = 001EFD70
        &_c = 001EFD70
        &_ro_c->_n = -858993460
        &_c->_n = -858993460
C::C(): _n = 123 ...and blowing up now!
Failed to create object of type A