Michael Shepanski wrote:
On 10/27/05, David Abrahams <dave@boost-consulting.com> wrote:
Sure, that's what we want. Can you figure out *how*? That's the problem.
I can't think of a perfect solution, but here are some imperfect ones:
1. Inside type_traits/alignment_of.hpp, the expression: sizeof(alignment_of_hack<T>)-sizeof(T) is what generates the number 12 in the first place. I think the 12 comes about because this expression includes the size of padding both before and after the t field in alignment_of_hack<T>. If you replace this expression with: offsetof(alignment_of_hack<T>, t) then it seems to work better. The downside is that the standard says you can't use offsetof with non-PODs, and gcc gives warnings if you try. This may be because offsetof relies on "&" --in which case boost::addressof will save the day-- but there may be more fundamental reasons to do with unpredictable layout of non-PODs.
Well, you said it yourself... we can't use this solution becasue it won't work for any T.
2. We could assume that the alignment of int64_t is good enough alignment for anything, and then set up type_with_alignment so that it gives you an int64_t by default, i.e. in the cases where it's currently failing. Downside: the assumption is probably not guaranteed by any C++ standard, so if you meet a platform where the assumption fails, then you'll need platform-specific code that sets a different default type.
Again, as you said, that assumption is not a std requirement so we can't use it.
3. boost::optional could put the data on the heap (since operator new always knows how to get properly aligned memory), and then boost::optional could manage it with a smart pointer. Downside: it defeats one of the attractions of boost::optional over smart pointers, which is that it saves the allocation and indirection overhead.
Is more than an attraction, it's a fundamental feature. I can't change that. FWIW, there is sound (IMO at least) alignment proposal for the std, so we may not need to worry anymore about this in the not so distant future. -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/