38

Is the following legal in C++?

As far as I can tell, Reference has a trivial destructor, so it should be legal.
But I thought references can't be rebound legally... can they?

template<class T>
struct Reference
{
    T &r;
    Reference(T &r) : r(r) { }
};

int main()
{
    int x = 5, y = 6;
    Reference<int> r(x);
    new (&r) Reference<int>(y);
}
templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
user541686
  • 205,094
  • 128
  • 528
  • 886
  • 5
    Not your downvoter, but I'm going to guess it was a knee jerk reaction to the horror of doing such a thing. Interesting question, though. – Fred Larson Jan 13 '14 at 21:40
  • 3
    These are definitely cases where the downvote should be undone by a mod or a community manager. It's just not justified. –  Jan 13 '14 at 21:42
  • 1
    Maybe I shouldn't have mentioned the triviality of the destructor at all -- I just realized that I could very well have done `r.~Reference()` before the placement-new, so whether or not the destructor is trivial doesn't really affect the question... – user541686 Jan 13 '14 at 22:01
  • @Mehrdad, But it did bring up some interesting discussion, which I find very nice. – chris Jan 14 '14 at 00:21

3 Answers3

18

You aren't rebinding a reference, you're creating a new object in the memory of another one with a placement new. Since the destructor of the old object was never run I think this would be undefined behavior.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • 3
    Could you elaborate on the destructor not being run? If it's trivial, is it really UB for it not to run? – chris Jan 13 '14 at 21:42
  • 5
    It's not automatically UB if a destructor is not run before the storage for an object is re-run, only "any program that depends on the side effects produced by the destructor has undefined behavior" (ISO/IEC 14882:2011 3.8 [basic.life] / 4) which leaves open the possibility for whole classes of programs to omit the call of destructors - even non-trivial ones - and not have UB. – CB Bailey Jan 13 '14 at 21:48
  • Yeah I think you missed the point of the question, @CharlesBailey hit the nail on the head. In fact I had no idea that non-trivial destructors could be omitted at will if we didn't depend on their effects... – user541686 Jan 13 '14 at 21:51
  • 1
    @CharlesBailey, thanks for the reference - is the destructor of a reference guaranteed to have no side effects? I can't think of a situation where it would, but my imagination has failed me before. – Mark Ransom Jan 13 '14 at 22:17
  • 2
    I don't think that references even have destructors. – CB Bailey Jan 13 '14 at 23:41
  • Are references "POD"? – user541686 Jan 14 '14 at 02:14
  • @Mehrdad, if I'm reading [this answer](http://stackoverflow.com/questions/4178175/what-are-aggregates-and-pods-and-how-why-are-they-special/4178176#4178176) correctly then they aren't. It contains quotes from the standard to back it up. I suppose it's to give some leeway to implementers. – Mark Ransom Jan 14 '14 at 02:57
  • @MarkRansom: Interesting... In that case they could have destructors I suppose? – user541686 Jan 14 '14 at 03:11
  • @Mehrdad: References aren't POD types but they also don't have destructors because they aren't class types. – CB Bailey Jan 14 '14 at 06:42
  • @CharlesBailey: Good point. I guess if they had destructors we would need to be able to call them... – user541686 Jan 14 '14 at 07:33
  • I think this is a valid [follow-up](http://stackoverflow.com/questions/20197636/is-it-ub-to-re-use-an-objects-storage-without-destroying-it-first) – Koushik Shetty Jan 14 '14 at 10:13
11

There is no reference being rebound in your example. The first reference (constructed on line two with the name r.r) is bound to the int denoted by x for the entire of its lifetime. This reference's lifetime is ended when the storage for its containing object is re-used by the placement new expression on line three. The replacement object contains a reference which is bound y for its entire lifetime which lasts until the end of its scope - the end of main.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • 1
    I wasn't so hooked up on the terminology ("rebinding") than the actual code... so the code is legal/well-defined? – user541686 Jan 13 '14 at 21:54
  • There is nothing wrong with the code, there is no UB at the end of `main` because Reference has a trivial destructor. Even if it didn't there would still be no UB because you ensure that an object of the correct type exists at the storage for `r` at the point where the implicit destructor call takes place - the end of `main`. – CB Bailey Jan 13 '14 at 21:56
  • 1
    Couldn't an optimizing compiler conclude that since the reference is known in that context and can't be rebound and hasn't been destroyed, that it could use the underlying source directly and miss the reconstruction entirely? – Mark Ransom Jan 13 '14 at 22:56
  • @MarkRansom I love that, it's an excellent point I hadn't thought of. Makes the question a lot more interesting! – user541686 Jan 13 '14 at 23:27
  • 2
    @MarkRansom: but the "hasn't been destroyed part" would be an incorrect assumption because reusing an object's storage for a different object destroys the original object. This implies that such an optimization would be non-conforming. – CB Bailey Jan 13 '14 at 23:40
  • By "hasn't been destroyed" I meant that a destructor hasn't been called. There are many different ways to overwrite an object's storage and I'd suspect most or all of them to be potential UB. – Mark Ransom Jan 13 '14 at 23:45
  • @MarkRansom: but references don't have destructors, besides, any object can be destroyed by having its storage reused. The resulting program only has UB if it relies on the side effects of the destructor being called which is a bit of a weak (meaningless?) requirement. There was some discussion about how meaningful this requirement really is here: http://stackoverflow.com/questions/10546695/do-we-need-to-explicitly-call-the-destructor-for-the-simple-pod-classes-alloca/10546830#10546830 – CB Bailey Jan 14 '14 at 06:58
  • @CharlesBailey: Yeah [I also asked something similar here](http://stackoverflow.com/questions/20541987/is-it-dangerous-to-use-placement-new-on-an-old-object-without-explicitly-calling/20545824#comment31746927_20545824), I don't know what that requirement means... – user541686 Jan 14 '14 at 07:36
  • @CharlesBailey, it doesn't matter if the reference doesn't have a destructor, the class containing it does. Even if the destructor is technically empty, the compiler will use it to determine the object lifetime in its static analysis. An object containing a reference isn't a POD so the link doesn't apply. – Mark Ransom Jan 14 '14 at 13:09
  • @MarkRansom: The part of the link that was meant to apply was the discussion about what depending on the side-effects of a non-trivial destructor really means. In any case, the non-PODness of the class is irrelevant. The class has no members or bases of class type (a reference type is not a class type) and the destructor is not user-declared so it is _trivial_ and there can be no UB caused by bypassing it. – CB Bailey Jan 14 '14 at 13:58
4

I think I found the answer in a passage below the "quoted" one that talks about trivial dtor / dtor side effects, namely [basic.life]/7:

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 storage for the new object exactly overlays the storage location which the original object occupied, and

  • the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and

  • 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 original object was a most derived object of type T and the new object is a most derived object of type T (that is, they are not base class subobjects).

By reusing the storage, we end the lifetime of original object [basic.life]/1

The lifetime of an object of type T ends when:

  • if T is a class type with a non-trivial destructor, the destructor call starts, or

  • the storage which the object occupies is reused or released.

So I think [basic.life]/7 covers the situation

Reference<int> r(x);
new (&r) Reference<int>(y);

where we end the lifetime of the object denoted by r, and create a new object at the same location.

As Reference<int> is a class type with a reference data member, the requirements of [basic.life]/7 are not fulfilled. That is, r might not even refer to the new object, and we may not use it to "manipulate" this newly created object (I interpret this "manipulate" also as read-only accesses).

dyp
  • 38,334
  • 13
  • 112
  • 177
  • Hmm although I've first read the conditions under which the lifetime ends as *either you call the dtor, or you reuse the storage*, I now think it's a strict separation: *either it has a non-trivial dtor and you call it, or you reuse the storage*. The example in [basic.life]/7 is not really helpful, as the dtor is trivial anyway (are you here, @Mehrdad?) – dyp Jan 15 '14 at 20:15
  • Yeah passage 1 seems to put a strict separation between the two, i didn't see it initially so I thought a lifetime can only end if there's a nontrivial dtor (from the other passage). The answer makes sense and is probably correct... let me think about it a bit more but I'll probably accept it, thanks! +1 – user541686 Jan 15 '14 at 20:20
  • @dyp, So, it is legal? – alfC Jun 21 '18 at 19:41
  • @alfC I'm a bit out of touch, but as far as I understand using the name `r` to access the object was and still is illegal because of the reference member. Nowadays, one can use [`std::launder`](https://en.cppreference.com/w/cpp/utility/launder) to get around some of the issues. – dyp Jul 12 '18 at 16:58