On Jun 14, 2006, at 5:04 PM, Gottlob Frege wrote:
Actually, after thinking about it a bit, I'm now tempted to say a 5 byte buffer should have 1 byte alignment. eg (given a typical platform):
struct test_alignment { int x; char y; };
<snip>
So, If sizeof(test_alignment) == 5, then the alignment must really be 1 (ie there is probably a pragma pack(1) in play).
Sure. Another way of stating it is that if alignment of test_alignment is 1, sizeof must be 5. However if the alignment of test_alignment is 4, then its sizeof must be 8 (on a typical desktop platform). On my system sizeof(test_alignment) is 8. The alignment and sizeof test_alignment is what it is for a given platform, and neither the standard nor the type_traits lib is going to change that. What the type_traits lib can do is help report those facts.
Also, in any case, for boost::type_with_alignment<5> doesn't compile. I think it should at least do something (or else the standard/docs need to have lots of wording explaining which ints work and which do not).
Similarly, aligned_storage has the same 'problem' and basically only works with alignment_of (or something that does the same thing).
I think failing to compile is exactly what should happen for unsupported alignments. Requesting an unsupported alignment is an error, and finding out at compile time is a feature, not a bug.
Since that is the case anyhow, I would suggest that aligned_storage be replaced with:
storage_for<T, count = 1>;
(which can be written in terms of aligned_storage and alignment_of, but since the two are tied together, and typically used together, why not just supply what is really wanted).
So really I'd like:
storage_for_type<T, size_t count = 1> and storage_for_size<size_t>
where storage_for_size determines the minimum necessary alignment based on the size, as discussed.
<shrug> storage_for_type<T, size_t> is a nice convenience function, and I can't get too worked up over it myself either for or against. Like you say, it can (easily) be written in terms of aligned_storage and alignment_of. In general I'm strongly in favor of a fundamental interface. Convenience functions built on top of the fundamental interface don't excite me very much either pro or con. Though std::basic_string did carry the convenience interface a little too far imho. Note that there are things you can do with aligned_storage that you can't do with storage_for_type (making it more fundamental). For example: aligned_storage<4096, 4096>::type page_buffer; No, it isn't portable. But it sure is valuable to be able to use this when you know you can (and yes, I'm on a platform where I can use 4096 byte alignment, and where it has uses). And if the code accidently gets ported to some place where it isn't supported, you find out at compile time (asap). -Howard