Aligned storage and standard layout

Question

Consider the following C++11 code:

#include <type_traits>

struct bar
{
    virtual void do_bar() const {}
};

struct foo
{
    std::aligned_storage<sizeof(bar),alignof(bar)>::type m_storage;
};

bar is not standard layout because of the virtual function do_bar(). However, foo is standard layout as the type provided by std::aligned_storage is a POD type and foo satisfies all the other requirements for standard layout types.

What happens then when I use the m_storage storage with placement new to construct an instance of bar? E.g.,

foo f;
::new(static_cast<void *>(&f.m_storage)) bar();

Is this legal? Can I use this to cheat my way around restrictions about standard layout types?

Answer 1

Here's your code again:

struct bar {
    virtual void do_bar() const {}
};

struct foo {
    std::aligned_storage<sizeof(bar), alignof(bar)>::type m_storage;
};

This is fine. struct foo is a standard-layout type, and, given an instance foo myFoo, you can construct an object of type bar into myFoo.m_storage.

However, this is completely pointless from the compiler's POV, so why bother with it? As @dyp wisely said in the comments, "Why do you want foo to be standard-layout?"

You handwaved something about unions. Well, that's fine. You can write this:

union DoesntWork {
    bar b;    // compiler error in C++11 due to non-standard-layout type
    int i;
};

union DoesWork {
    foo f;    // works fine in C++11, of course
    int i;
};

However, equally obviously, you cannot expect this to work:

struct car {
    int initialsequence;
};
struct bar {
    int initialsequence;
    virtual void do_bar() const {}
};
struct foo {
    std::aligned_storage<sizeof(bar), alignof(bar)>::type m_storage;
    bar& asBar() { return *reinterpret_cast<bar*>(&m_storage); }
};

union JustSilly {
    foo f;
    car c;
} js;
assert(&js.c.initialsequence ==         // Fails, because no matter how many
       &js.f.asBar().initialsequence);  // casts you add, bar still has a vptr!

In other words, you're free to lie to the compiler (via type-punning and reinterpret_cast), but that doesn't make your lies true. ;)

See also: XY problem.