Is constructing objects in a char array well-formed

Question

This is almost standard textbook use of placement new

template<size_t Len, size_t Align>
class aligned_memory
{
public:
    aligned_memory() : data((char*)(((std::uintptr_t)mem + Align - 1) & -Align)) {}
    char* get() const {return data;}
private:
    char mem[Len + Align - 1];
    char* data;
};

template<typename T, size_t N>
class Array
{
public:
    Array() : sz(0) {}
    void push_back(const T& t)
    {
        new (data.get() + sz++ * sizeof(T)) T(t);
    }
    void pop_back()
    {
        ((T*)data.get() + --sz)->~T();
    }

private:
    aligned_memory<N * sizeof(T), alignof(T)> data;
    size_t sz;
};

Seems pretty fine, until we look into strict-aliasing, there seems to be some conflict in whether this is well-formed

Camp ill-formed

• C++'s Strict Aliasing Rule - Is the 'char' aliasing exemption a 2-way street?
• Strict aliasing rule and 'char *' pointers

Camp well-formed

• Does encapsulated char array used as object breaks strict aliasing rule
• How to avoid strict aliasing errors when using aligned_storage

They all agree on char* may always reference another object, but some point out its ill-formed to do so the other way round.

Clearly our char[] converts to char* then casted to T*, with which it is used to call its destructor.

So, does the above program break the strict-aliasing rule? Specifically, where in the standard does it says it is well-formed or ill-formed?

EDIT: as background info, this is written for C++0x, before the advent of alignas and std::launder. Not asking specifically for a C++0x solution, but it is preferred.

alignof is cheating, but its here for example purposes.

Answer 1

Gathering from the hints throughout the countless helpful comments, here is my interpretation of what's happening.

TLDR its well-formed^{‡see edit}

---

Quoting in the order I find more logical from [basic.life]^†

The properties ascribed to objects and references throughout this International Standard apply for a given object or reference only during its lifetime.

---

An object is said to have non-vacuous initialization if it is of a class or aggregate type and it or one of its subobjects is initialized by a constructor other than a trivial default constructor. [...] The lifetime of an object of type T begins when:

• storage with the proper alignment and size for type T is obtained, and

• if the object has non-vacuous initialization, its initialization is complete.

---

The lifetime of an object o 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 released, or is reused by an object that is not nested within o

From [basic.lval]^†

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined

• the dynamic type of the object,

• a cv-qualified version of the dynamic type of the object,

• a type similar to the dynamic type of the object,

• a type that is the signed or unsigned type corresponding to the dynamic type of the object,

• a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,

• an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),

• a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,

• a char, unsigned char, or std​::​byte type.

We deduce that

1. The lifetime of the chars in the char[] ends when another object reuses that space.

2. The lifetime of an object of type T started when push_back is called.

3. Since the address ((T*)data.get() + --sz) is always that of an object with type T whose lifetime has started and not yet ended, it is valid to call ~T() with it.

4. During this process, the char[] and char* in aligned_memory aliases objects of type T but it is legal to do so. Also, no glvalue is obtained from them, so they could have been pointers of any type.

To answer my own question in the comments whether using any memory as storage is also well-formed

U u;
u->~U();
new (&u) T;
((T*)&u)->~T();
new (&u) U;

Following the 4 points above, the answer is yes^{‡see edit}, as long as the alignment of U is not weaker than T.

‡ EDIT: I've neglected another paragraph of [basic.life]

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).

Which means even though using the object is well-formed, the means which the object is obtained is not. Specifically, post C++17, std::launder has to be called

(std::launder((T*)data.get()) + --sz)->~T();

Prior C++17, a workaround would be to use the pointer acquired from the placement new instead

T* p = new (data.get() + sz++ * sizeof(T)) T(t);  // store p somewhere

_{† Quoted from n4659, as far as I can see, same holds for n1905}

Answer 2

Placement-new creates an object at the specified location (C++14 expr.new/1), and ends the lifetime of any other object that was occupying the location (basic.life/1.4).

The code ((T*)data.get() + --sz)->~T(); accesses an object of type T at the location where there is an object of type T. This is fine. It is irrelevant if there used to be a char array at the location.