From: Robert Ramey (ramey_at_[hidden])
Date: 2004-03-06 13:25:42
Tom Widmer wrote:
>On Fri, 5 Mar 2004 07:59:31 -0800, "Robert Ramey" <ramey_at_[hidden]>
>>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
>>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
>>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:
>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 must be a complete 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk