# Why does std::aligned_storage work only with POD?

This topic is 1259 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

For what sane reason they made this work:
auto alignValue = 16;

class Foo
{
public:
Foo();
~Foo();
private:
MyMatrix matrix;
}

typedef aligned_storage< sizeof( Foo ), alignValue >::type FooAligned


But not this:
auto alignValue = 16;

class Foo
{
public:
Foo();
~Foo();

void doSomething();

private:
MyMatrix matrix;
}

typedef aligned_storage< sizeof( Foo ), alignValue >::type FooAligned


##### Share on other sites
From what I can see both should work. std::aligned_storage<> has no relation with the type Foo at all and you would have to do placement new/explicit destruction in both cases. What are the errors you are getting?

##### Share on other sites
According to the internet, ccpreference.com as example, std::aligned_storage works only with PODs: http://en.cppreference.com/w/cpp/types/aligned_storage

I don't understand why it shouldn't work with structs/classes that have member function/methods. Edited by Alessio1989

##### Share on other sites
Neither of your classes are "POD" because you don't have trivial destructors and constructors.

Adding a non-virtual function do a class does not change it's "POD-ness". "POD" is also a deprecated term in the new standard and it is preferred to talk about classes in terms of being trivial, standard-layout, or both. By extension, a "POD" is a class that is both trivial and standard-layout.

As BitMaster pointed out - need more information to determine why it isn't working.

##### Share on other sites

You're misreading things. That link says std::aligned_storage<>::type is POD, it doesn't say anything about any restrictions on the type you use sizeof on to get the size.

##### Share on other sites

According to the internet, ccpreference.com as example, std::aligned_storage works only with PODs: http://en.cppreference.com/w/cpp/types/aligned_storage

I don't understand why it shouldn't work with structs/classes that have member function/methods.

There is no requirement on aligned_storage and POD types - it is simply stating that aligned_storage::type IS a POD type. All aligned_storage::type is is a blank swath of memory that you can placement-new into. If you scroll down on that page you can see that their own example uses std::string which definitely is not a POD type.

Edit: Ninja'd Edited by SmkViper

##### Share on other sites
I checked the same reference. std::aligned_storage<> works by creating a convenient POD-type which contains uninitialized memory. The POD-type has nothing to do with Foo.

This memory can then be used to placement new construct your Foo in. If you know your Foo is std::is_trivially_copyable (you don't need the whole std::is_pod) you don't need placement new/manual destruction and can just use memcpy.

Edit: Also ninja'd. Edited by BitMaster

##### Share on other sites
OK thank you all, I learned something new today

Anyway since I discover that MSVC12 uses 16-byte align as default, even on heap, on x86-64 platform (and not 8-byte like in x86-ia32 and ARM), I don't need it at all xD Edited by Alessio1989

##### Share on other sites

OK thank you all, I learned something new today

Anyway since I discover that MSVC12 uses 16-byte align as default, even on heap, on x86-64 platform (and not 8-byte like in x86-ia32 and ARM), I don't need it at all xD

I wouldn't make a habit of depending on implementation defined behavior like that.

##### Share on other sites

OK thank you all, I learned something new today

Anyway since I discover that MSVC12 uses 16-byte align as default, even on heap, on x86-64 platform (and not 8-byte like in x86-ia32 and ARM), I don't need it at all xD

I wouldn't make a habit of depending on implementation defined behavior like that.

I know, but I'am actually studying and coding only on Windows 64 and only for x86-64 platform (x86-ia32 just add to much useless restrictions and hopefully one day will remain into OSs just for compatibility with legacy applications). Edited by Alessio1989

##### Share on other sites

OK thank you all, I learned something new today

Anyway since I discover that MSVC12 uses 16-byte align as default, even on heap, on x86-64 platform (and not 8-byte like in x86-ia32 and ARM), I don't need it at all xD

I wouldn't make a habit of depending on implementation defined behavior like that.

While it's generally good advice to not rely on implementation defined behavior, memory alignment is one of those things you usually want the compiler to just handle for you, as it knows your target platform better then you do. If you force alignment of things to make it "portable" then at best it will have no effect and at worst you'll get terrible performance or crashes due to mis-aligned memory on some of your platforms.