3 ms·
If you assign the initialized value to a variable then you get the expected behavior: https://wandbox.org/permlink/r6csgR44BZBWudLV https://wandbox.org/permlink
by mnarayan01 9y ago
If you assign the initialized value to a variable then you get the expected behavior: https://wandbox.org/permlink/r6csgR44BZBWudLV https://wandbox.org/permlink/r6csgR44BZBWudLV. What exactly is the defined destruction behavior for an object that's never (necessarily) on the stack? Or is it actually required to be on the stack in this case?
- JonathonW 9y agoIn C++14, the spec specifies that a temporary object's destructor is called as the last step in evaluating the full expression that contains the point where it was created (C++14 §12.2). I'm presuming it's the same in earlier versions of the language, but I don't have those specs handy ATM.
- maxlybbert 9y agoI don't have the specs either, but I do remember that in Design and Evolution of C++, Stroustrup discusses nailing down the lifetime of temporary objects. I believe it was in the first standard (i.e. 1998).
- mnarayan01 9y agoI'm more talking about the exception behavior looking at e.g. https://wandbox.org/permlink/S5paK3Z9NpeCv3I0 https://wandbox.org/permlink/S5paK3Z9NpeCv3I0 (which exhibits the same bug). I mean you're right, and the fact that the User object is temporary should presumably not keep the first Resource destructor from firing, just it seems weird. I guess in my defense, apparently it seems weird to GCC as well.
- JonathonW 9y agoThe spec also explicitly addresses that (automatic objects' destructors must be called after an exception)-- see section 15.2 in the C++14 spec. There is no ambiguity in the spec here; this is a GCC bug.