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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-02-25 20:05:02

"Philippe A. Bouchard" <philippeb_at_[hidden]> escribió en el mensaje
news:b3eqcs$94d$1_at_main.gmane.org...
> 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.
>
Aha, now I know what did you mean... "within" optional<>, m_storage is
aligned to the
next word boundary... I agree this would be the case if
sizeof(bool)==sizeof(int).

Ithough you were talking about m_storage itself, that is, of
aligned_storage<T> per se.

Anyway, just for the record, the C++ type 'bool' has an 'underlying type'
which is required
to be one of the integer types but not necessarily 'int'.

> > [snip optimized array<bool,N>]
>
> 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.
>
That would have to be _measured_; my guess is that it could be twice slower,
specially considering that I don't think boost sources will ever include
assembly
code; it's a portability nightmere.

>
> > 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.
>
Yes, though I still can't see if this would be _needed_.

Fernando Cacciola