Tom Widmer wrote:
On Fri, 5 Mar 2004 07:59:31 -0800, "Robert Ramey" <ramey@rrsd.com> wrote:
Joaqu?n M? L?pez Mu?oz wrote:
"serialization/collections_load_imp.hpp" defines a private template class stack_allocate for stack-based reservation of uninitialized memory. To the best of my knowledge, the way it does so is not std-conformant due to alignment issues. Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a template class named aligned_storage which handles the issue, so I guess the problem can be solved by just using this facility instead of stack_allocate.
This has been mentioned before. I was unable to find any information other than the code itself which wasn't all that transparent to me. And the stack allocate was soooooo simple. Is aligned_storage part of boost? Is it documented anywhere? Is it part of any test suite? Has it been tested for portability? In general I would prefer a boostified component over a homebrew one. I'm really not sure of what the status of aligned_storage is. Also, the nameitself didn't make it clear to me that its intended purpose was identical to that implemented by stack_allocate.
It's a fully documented part of Boost type_traits, assuming you are just after a POD type with a certain alignment:
::boost::alignment_of<T>::value Identifies the alignment requirements of T. Actually returns a value that is only guaranteed to be a multiple of the actual alignment requirements of T. T must be a complete type.
::boost::type_with_alignment<Align>::type Attempts to find a built-in or POD type with an alignment that is a multiple of Align.
Neither of the above functions is the on in question. We're talking about aligned_storage here. This exchange illustrates the problem rather nicely. Its not clear to me from the name "aligned_storage" that its meant to do the same job as "stack_allocate" and in fact is easily confused with other boost functions. I've been able to find no documentation nor test nor other information. The only place its used is in variant.hpp but its not mentioned in the documentation of that either. There is no statement in the header itself as to what it does and the code is sufficiently non-trivial that it's not obvious what its supposed to do. The fact that it has a parameter than stack_allocate doesn't need also suggests that it's intended purpose is different from that of stack_allocate. Given all the above, I would be reluctant to replace the 10 transparently correct lines of stack_allocate by inclusion of 138 lines of aligned_storage. Now it's quite possible that stack_allocate is incorrect, non-portable, or in some other way undesirable such that it should be replaced with something else. If this is the case, I would very much like hear about it. Robert Ramey