[boost] Re: Re: Re: Re: Re: partial<> proposal

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
> 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