boost::aligned_storage is supposed to be an implementation of TR1 aligned_storage, which yields a POD. I even see a specialization of is_pod for aligned_storage in the header. However the class itself (::type only echoes its type back) does not seem a POD at all. It has a default constructor, destructor, a private copy constructor and whatnot. aligned_storage_test does not test its PODness, it only looks at is_pod. I think that a reasonable test for PODness would be to try to initialize with = {} (if nonscalar) and/or use it in a union. -- Peter Dimov http://www.pdimov.com
"Peter Dimov" <pdimov@mmltd.net> writes:
boost::aligned_storage is supposed to be an implementation of TR1 aligned_storage, which yields a POD. I even see a specialization of is_pod for aligned_storage in the header. However the class itself (::type only echoes its type back) does not seem a POD at all. It has a default constructor, destructor, a private copy constructor and whatnot. aligned_storage_test does not test its PODness, it only looks at is_pod.
Wow, that is embarassing!
I think that a reasonable test for PODness would be to try to initialize with = {} (if nonscalar) and/or use it in a union.
Good idea. Who is responsible for this code? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Good idea. Who is responsible for this code?
A while ago I promised a patch that would: 1) Shift the code into boost/type_traits, 2) Make it TR1 conforming. 3) Apply patches to existing clients of aligned_storage. I haven't got around to (3) yet, but there's a good chance I'll do it early next week. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Good idea. Who is responsible for this code?
A while ago I promised a patch that would:
1) Shift the code into boost/type_traits, 2) Make it TR1 conforming. 3) Apply patches to existing clients of aligned_storage.
I haven't got around to (3) yet, but there's a good chance I'll do it early next week.
I don't understand what 3 might entail. Are these fixes to aligned_storage already done, and how can they possibly cause clients to require being patched? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Good idea. Who is responsible for this code?
A while ago I promised a patch that would:
1) Shift the code into boost/type_traits, 2) Make it TR1 conforming. 3) Apply patches to existing clients of aligned_storage.
I haven't got around to (3) yet, but there's a good chance I'll do it early next week.
I don't understand what 3 might entail. Are these fixes to aligned_storage already done, and how can they possibly cause clients to require being patched?
I think that it would be easier to just define a proper ::type in aligned_storage (data_t, the type of its data_ member, should do). The test needs to be fixed first, of course.
I don't understand what 3 might entail. Are these fixes to aligned_storage already done, and how can they possibly cause clients to require being patched?
They're only done in the sense that for a while we had two aligned_storage classes in cvs: a strictly conforming TR1 version and the old version: I removed the new version just to get things working again, after consultation with Eric Friedman the plan was to deprecate the old version eventually. However.... on reflection it's too close to release, so I'll do what Peter suggested, and just make sure that aligned_storage::type conforms to the TR, even though aligned_storage itself contains all kinds of "enhancements". That won't affect any existing code BTW. John.
John Maddock wrote:
I don't understand what 3 might entail. Are these fixes to aligned_storage already done, and how can they possibly cause clients to require being patched?
They're only done in the sense that for a while we had two aligned_storage classes in cvs: a strictly conforming TR1 version and the old version: I removed the new version just to get things working again, after consultation with Eric Friedman the plan was to deprecate the old version eventually. However.... on reflection it's too close to release, so I'll do what Peter suggested, and just make sure that aligned_storage::type conforms to the TR, even though aligned_storage itself contains all kinds of "enhancements". That won't affect any existing code BTW.
Right now, the following code will not compile for me: typename aligned_storage < sizeof ( MyClass ) >::type storage; this was formerly: aligned_storage < sizeof ( MyClass ) > storage; but I added the ::type after reading the above message. Am I doing something wrong, or do I just need an up to date version of the library? I am using VC 7.1 and get the error: error C2039: 'MyClass' : is not a member of 'boost::aligned_storage<size_>' -Jason
Right now, the following code will not compile for me: typename aligned_storage < sizeof ( MyClass ) >::type storage; this was formerly: aligned_storage < sizeof ( MyClass ) > storage; but I added the ::type after reading the above message. Am I doing something wrong, or do I just need an up to date version of the library?
I am using VC 7.1 and get the error: error C2039: 'MyClass' : is not a member of 'boost::aligned_storage<size_>'
OK, lets take this a step at a time: 1) You didn't need to change anything, the whole point was that no existing code should break. 2) The code you posted above should non-the-less compile. Are you using the latest cvs? The error message also looks strange: 'MyClass' is not a member of aligned_storage after all! Can you double check there are no obvious typos in your code? Can you check that the latest aligned_storage_test.cpp in libs/type_traits/test compiles for you? And if all else fails mail me a test case and I'll look into it. HTH, John.
John Maddock wrote:
Right now, the following code will not compile for me: typename aligned_storage < sizeof ( MyClass ) >::type storage; this was formerly: aligned_storage < sizeof ( MyClass ) > storage; but I added the ::type after reading the above message. Am I doing something wrong, or do I just need an up to date version of the library?
I am using VC 7.1 and get the error: error C2039: 'MyClass' : is not a member of 'boost::aligned_storage<size_>'
OK, lets take this a step at a time:
1) You didn't need to change anything, the whole point was that no existing code should break.
Ok, I was just thinking that using aligned_storage instead of aligned_storage::type might have been an invalid usage from the beginning (I probably should have tracked down the documentation).
2) The code you posted above should non-the-less compile. Are you using the latest cvs?
No I wasn't. I am now, and the problem has gone away :) However, I am worried that people who still have the old version of aligned_storage may be unable to test my singleton library when it comes up for review. It appears that aligned storage itself is not a POD, so the ::type is necessary. Should I package the new version of aligned_storage with the singleton zip so that testers will not run into problems?
The error message also looks strange: 'MyClass' is not a member of aligned_storage after all!
My mistake, that should read: error C2039: 'type' : is not a member of 'boost::aligned_storage<size_>' I was trying to translate a more complex use case and error message to a simpler one, which I should have compiled independently. -Jason
Ok, I was just thinking that using aligned_storage instead of aligned_storage::type might have been an invalid usage from the beginning (I probably should have tracked down the documentation).
Actually there wasn't any until I added it with the updated version!
2) The code you posted above should non-the-less compile. Are you using the latest cvs?
No I wasn't. I am now, and the problem has gone away :) However, I am worried that people who still have the old version of aligned_storage may be unable to test my singleton library when it comes up for review. It appears that aligned storage itself is not a POD, so the ::type is necessary. Should I package the new version of aligned_storage with the singleton zip so that testers will not run into problems?
That sounds like a reasonable solution: it's only one file after all, and I think you probably really do want a POD type when building a singleton (but just guessing on my part, I haven't looked at your code yet).
The error message also looks strange: 'MyClass' is not a member of aligned_storage after all!
My mistake, that should read: error C2039: 'type' : is not a member of 'boost::aligned_storage<size_>'
I was trying to translate a more complex use case and error message to a simpler one, which I should have compiled independently.
No problem, glad it was easily fixed, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
It appears that aligned storage itself is not a POD, so the ::type is necessary.
I can't imagine what would necessitate making aligned_storage<T> not a POD. Can somebody please explain? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
It appears that aligned storage itself is not a POD, so the ::type is necessary.
I can't imagine what would necessitate making aligned_storage<T> not a POD. Can somebody please explain?
It has user defined constructors (to make it non-copyable), and private data. I don't know why it was done that way, I'm just trying to make sure that the ::type member is TR1 conforming. BTW using aligned_storage directly like that (not going through the ::type member), is and always has been, untested and undocumented. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
It appears that aligned storage itself is not a POD, so the ::type is necessary.
I can't imagine what would necessitate making aligned_storage<T> not a POD. Can somebody please explain?
It has user defined constructors (to make it non-copyable), and private data. I don't know why it was done that way,
Overzealous obsession with safety, I bet.
I'm just trying to make sure that the ::type member is TR1 conforming.
BTW using aligned_storage directly like that (not going through the ::type member), is and always has been, untested and undocumented.
Oh. Well, that's fine, then. Thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Jason Hise -
John Maddock -
Peter Dimov