Title
Type consistency and reallocation of scalar types
Status
review
Section
6.7.3 [basic.life]
Submitter
Gabriel Dos Reis

Created on 2010-02-03.00:00:00 last changed 11 months ago

Messages

Date: 2010-08-15.00:00:00

Proposed resolution (August, 2010) [SUPERSEDED]:

This issue is resolved by the resolution of issue 1116.

Possible resolution:

  1. Change in 6.7.3 [basic.life] paragraph 6 as follows:

    Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [ Footnote: ... ], or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways. ...
  2. Change in 6.7.3 [basic.life] paragraph 7 as follows:

    Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated, or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways. ...
Date: 2012-09-24.00:00:00

Is the following well-formed?

    int f() {
        int i = 3;
        new (&i) float(1.2);
        return i;
    }

The wording that is intended to prevent such shenanigans, 6.7.3 [basic.life] paragraphs 7-9, doesn't quite apply here. In particular, paragraph 7 reads,

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 problem here is that this wording only applies “after the lifetime of an object has ended and before the storage which the object occupied is reused;” for an object of a scalar type, its lifetime only ends when the storage is reused or released (paragraph 1), so it appears that these restrictions cannot apply to such objects.

(See also issues 1116 and 1338.)

History
Date User Action Args
2023-12-13 07:22:24adminsetstatus: drafting -> review
2010-11-29 00:00:00adminsetstatus: ready -> drafting
2010-08-23 00:00:00adminsetmessages: + msg2761
2010-08-23 00:00:00adminsetstatus: open -> ready
2010-02-03 00:00:00admincreate