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

From: Pablo Aguilar (pablo.aguilar_at_[hidden])
Date: 2005-08-22 04:32:10

Thanks!

I've updated the implementation to use this.

I'm still missing a proper implementation for optimized, different type 
swap, and a stronger exception safety guarantee for assignment.

The latest version is available at the same place: http://tinyurl.com/9wv28

Tested and worked on VC6, VC7.1 and BC6

Pablo

> 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