Sign in to follow this  

Why does std::aligned_storage work only with POD?

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

If you intended to correct an error in the post then please contact us.

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

Just asking.... 'Cause new and delete overloading is so annoying and so '90ish sleep.png Edited by Alessio1989

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

OK thank you all, I learned something new today tongue.png

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 this post


Link to post
Share on other sites

OK thank you all, I learned something new today tongue.png

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 this post


Link to post
Share on other sites

OK thank you all, I learned something new today tongue.png

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.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this