From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2005-08-19 08:41:16
> First of all, thanks to everyone who's commented on the proposed any
> alternative.
>
> Given that the alignment issue doesn't seem to be easy to solve, I'm
> thinking of giving up on trying to align correctly, and just skip the
> "in place storing of value" optimization when it might be an issue.
>
> So I'm wondering, is the following a proper way to detect alignment
> problems?
I don't remember exactly the case but the problem was to store a member
buffer properly aligned, so that it could be used instead of the dynamic
allocation. I don't know if this can be enough for you but in my Shmem
library I use boost::detail::max_align alignment to detect the most
restrictive alignment of the platform so that I align memory returned
from allocators to that boundary.
alignment_of_max_align =
::boost::alignment_of<::boost::detail::max_align>::value
Normally, the result is a 8 byte alignment. You could use an array of
max_align structs as the buffer and overwrite it, since in practice the
alignment is 8 bytes and max_align is usually 8 bytes so:
template <...>
class any
{
//Use a max_align arry as buffer
boost::detail::max_align[max_bytes/sizeof(boost::detail::max_align]buf;
};
8 byte alignment align it anyways acceptable and although you round the
buffer size to 8 bytes and waste 7 bytes for a single char, a call to
"new" is going to waste at least 8 bytes in bookeeping and another 8
rounding it to the most restrictive alignment, becouse although new
knows the type, is usually implemented on top of malloc.
The member buffer will speed up allocations A LOT, because apart from
avoiding the dynamic allocation to a stack pointer increment, it will
avoid the mutex locking new usually has in multithreaded enviroments.
Hope this works,
Ion