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