Can you think of anything wrong with this code.

[PredicateNormative]

>> template <typename U>
>> node(const node<U>& other)
>> :object_memory_(operator new(sizeof(T)))
Should that be sizeof(U)?

gg

It would have done, but a few lines down, you will see that I use placement new to copy construct a U to a value_type which is a T, so the type that resides in the allocation is a T type.

[OReubens]

Although I find your post helpful, please can you expand upon the part of your quote in bold? I'm not sure that I am correctly understanding what you are saying. It would seem that you are suggesting that operator new does not guarantee that the returned pointer for the requested memory (sizeof(T) ) is guaranteed to be correctly aligned for an object of type T.

that is is exactly what I'm saying. for VC, memory allocation via new will be 8 byte aligned regardless of alignment requirements of the object (that is for the total allocation not for allocation of individual elements within an array which will be consecutive as expected).

if you need alignment more strict than 8 bytes, then you'll have to do that yourself.

Other compiler may have similar things happening on allocated memory.

However, I'm not sure if that is what you mean. If it is though, then I would point out that the C++ standard states:

The section in bold infers that the allocation returned by the allocator must be appropriately aligned for an object of type T since no room for extra allocation is allowed. In fact the following section of the standard would seem to support that:

that section says nothing about alignment at all actually. it merely states that alignment must allow pointers and pointer dereferences. This is more a section intended for computers/wompilers were a 'char' may be more than 8 bits (yes, they do exist). It actually says nothing at all about additional alignment imposed on the object through 'nonstandard' means like #pragma pack, __align, __declspec(align(#))... and such.

it's actually easy to verify. create a structure. force it to align on something bigger than 16 (if your compiler supports it), such as 64 or 256.
Allocate some objects, I don't think I've seen a compiler yet that honors the alignment through new in this case (but they do for global memory).



it even says so in the MSDN help for __declspec(align) at http://msdn.microsoft.com/en-us/library/83ythb65.aspx
"To create an array whose base is properly aligned, use _aligned_malloc, or write your own allocator. Note that normal allocators, such as malloc, C++ operator new, and the Win32 allocators return memory that will most likely not be sufficiently aligned for __declspec(align(#)) structures or arrays of structures."

[PredicateNormative]

that is is exactly what I'm saying. for VC, memory allocation via new will be 8 byte aligned regardless of alignment requirements of the object (that is for the total allocation not for allocation of individual elements within an array which will be consecutive as expected).

if you need alignment more strict than 8 bytes, then you'll have to do that yourself.

Other compiler may have similar things happening on allocated memory.




that section says nothing about alignment at all actually. it merely states that alignment must allow pointers and pointer dereferences. This is more a section intended for computers/wompilers were a 'char' may be more than 8 bits (yes, they do exist). It actually says nothing at all about additional alignment imposed on the object through 'nonstandard' means like #pragma pack, __align, __declspec(align(#))... and such.

it's actually easy to verify. create a structure. force it to align on something bigger than 16 (if your compiler supports it), such as 64 or 256.
Allocate some objects, I don't think I've seen a compiler yet that honors the alignment through new in this case (but they do for global memory).



it even says so in the MSDN help for __declspec(align) at http://msdn.microsoft.com/en-us/library/83ythb65.aspx
"To create an array whose base is properly aligned, use _aligned_malloc, or write your own allocator. Note that normal allocators, such as malloc, C++ operator new, and the Win32 allocators return memory that will most likely not be sufficiently aligned for __declspec(align(#)) structures or arrays of structures."

Ok, your post has just shattered my trust in alignment guarantees for non-standard alignment of objects that are not automatic. Although I don't have time now, at the my available opportunity, I'll write down some thoughts in order to get clarification as to whether or not I have fully understood the implications of what you are saying.

P.s. Thanks for ruining my day.

[OReubens]

Thanks for ruining my day.

Happy to oblige

it's still better to figure this stuff out early when you just have a day ruined.
it can ruin weeks if you discover stuff like this when you're near the end of your development cycle or worse, if you only discover this when you deploy the application on the server/computer of that really really super important client and the whole stuff blows up in your face when you're demonstrating your product.