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
> instance.
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,
size_t>:
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
