Re: [boost] [Repost][RFC] Alternative any design

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