Boost logo

Boost :

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 =

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

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,


Boost list run by bdawes at, gregod at, cpdaniel at, john at