Re: Storing const references to other objects in another object.

From:

"Leigh Johnston" <leigh@i42.co.uk>

Newsgroups:

comp.lang.c++

Date:

Wed, 7 Apr 2010 19:45:17 +0100

Message-ID:

<T7KdnfIRcOxXTyHWnZ2dnUVZ7qGdnZ2d@giganews.com>

"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:OcSdnZ_QT_rSUyHWnZ2dnUVZ8k6dnZ2d@giganews.com...

"Keith H Duggar" <duggar@alum.mit.edu> wrote in message
news:92d5c379-4a3d-43f8-a62a-e31fc147dbe1@22g2000vbg.googlegroups.com...

On Apr 7, 1:28 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:

"Leigh Johnston" <le...@i42.co.uk> wrote in message

"Kai-Uwe Bux" <jkherci...@gmx.net> wrote in message

Leigh Johnston wrote:
[...]

It is possible to re-seat a member reference in a user provided
assignment
operator by doing something similar to the following:

const foo& foo::operator=( const foo& other)
{
  if ( this != &other )
  {
    this->~foo(); // lifetime of *this ends
    new (this) foo(other); // new object of type foo created
  }
  return *this;
}

Actually, I re-read [3.8/7]; and now I find that the above is not
solving
the problem of reseating references. [3.8/7] states:

If, after the lifetime of an object has ended and before the storage
which
the object occupied is reused or released, a new object is created
at
the
storage location which the original object occupied, a pointer that
pointed
to the original object, a reference that referred to the original
object, or
the name of the original object will automatically refer to the new
object
and, once the lifetime of the new object has started, can be used to
manipulate the new object, if:
...
? the type of the original object is not const-qualified, and, if a
class
type, does not contain any non-static data member whose type is
const-
qualified or a reference type, and
...

The operational words are "or a reference type".

BTW: this is also in n3035.

Best

Kai-Uwe Bux

Ah well spotted I failed again, damn UB. :)

For the record I have never done such a thing in real code. :)

And I would never have considered trying or recommending such a thing if
it
wasn't for that damn example in 3.8/7 which I agree is bad practice (too
easy to invoke UB by mistake).

Exactly. Hence the common recommendation to use pointers as
members instead and be done with it. Do you still disagree
with this general advice and hold that "it is perfectly fine
to have reference member variables"? If so I'm starting to
wonder if we mean different things by the word "fine".

I do disagree with that as general advice yes. If there is no need for a
class to be Assignable then reference members are fine. Not all classes
need to be assignable. A container can hold
shared_ptr<non_assignable_type> or unique_ptr<non_assignable_type>
elements. It is also possible to have a container of assignable elements
which all share the an identical reference member (to some parent class
perhaps) if an assignment operator is provided by the user.

It is sufficient to be aware that containers require Assignable elements
and classes with reference members are not assignable by default, this is
the general advice I do agree with.

/Leigh

As long as you don't have to go through hoops to use them the semantics of
references compared to pointers can be beneficial. I tend to prefer
references to enforce ownership relationships as a reference cannot outlive
what it refers to so using them makes ownership explicit/obvious compared to
(non-const) pointers whose values can change once initialized.

The following idiom is quite common in my code:

class foo
{
  class bar
  {
  private:
    foo& iParent;
    state iState;
  public:
    bar(foo& aParent, const state& aState) : iParent(aParent),
iState(aState) {}
    bar& operator=(const bar& other) { /* copy state, iParent should be the
same */ }
    /* bar functionality some of which refers to parent */
  };
  std::vector<bar> iChildren;
};

/Leigh