From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-02-24 23:11:21
Fernando Cacciola wrote:
> It seems there is something one of us don't understand...
> optional<T>::m_storage has nothing to do with alignment to 'int'
> unless T happens to be aligned just like 'int', which won't always be
> the case, so I don't
> see the relation between optional's storage and the correlation
> bool<->int you
> make above.
> For example, the storage for optional<long double> won't be aligned
> to a double-word boundary like 'int' does on 32-bit platforms, for
Yes it does, because m_storage is preceded by m_initialized which is of type
bool in optional<>. m_storage will thus follow bool alignment requirement.
>> This means that it *must* be constructed sooner or later?
> Some object must be constructed sooner or later within the aligned
> storage, yes,
> but that's not the job of aligned_storage itself, just as it is not
> the job for
> operator new.
Yes, it the users' responsability to do so.
> No, it isn't.
> But anyway, remember that bit-allocation _necesarily_
> optimizes size at the expense of speed.
It's true. Imagine we have some partial specialization of array<bool,
template <unsigned int I>
struct array<bool, I>
char value_[I >> 3];
// Read-only version:
bool operator  (unsigned int a_index) const
return value_[a_index >> 3] & (1u << (a_index % 8));
I could have made a mistake in my example, but operator  in assembler code
will be quite fast (and, shl, ...) when it comes to logical operations. I
don't think it will be twice slower.
> So, what are you trying to optimize with this bool array?
> and most importantly, why do you feel that such optimization is
> needed? Consider that gaining storage, say 31 bits, per optional<>
> will incurr in
> a significant overhead, so in order to think that the gain is needed
> you need to weight size/speed benefits.
> This sort of things are typically considered only afer some benchmarks
> shown the need for the optimization.
Even tough array<bool> is not optimized, the boolean values will follow each
other and will not waste any space between themselves.
Philippe A. Bouchard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk