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

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

"Philippe A. Bouchard" <philippeb_at_[hidden]> escribió en el mensaje
news:b3ec03$rhe$1_at_main.gmane.org...
> Fernando Cacciola (Home) wrote:
>
> [...]
>
> >> Well it depends on the platform but if sizeof(bool) == sizeof(int) on
> > Intel,
> >
> > ^^^^^^^
> > Were does this 'int' comes from?
>
> sizeof(bool) may vary, you just don't know (1, 4, 8, ...).  On Intel, if
> sizeof(bool) == 4 == sizeof(int) optional<>::m_storage will be aligned to
> the next integer boundary.
>
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.

>
> >> m_storage will be aligned to the next word boundary i.e. aligned
> >> like an integer.
> >>
> > Anyway, you just said that it depends on the platform, so I wouldn't
> > say
> > that m_storage *is*
> > aligned like bool, at most, it could be.
>
> Yes, exactly.
>
> >>>> - Maybe aligned_storage<> should always destruct its object.  It
> >>>> would be the user's responsability to construct the object before
> >>>> its destruction, otherwise the result would be undefined.
> >>>>
> >>> Why would this be useful?
> >>
> >> I don't know, it is just another alternative that I personally
> >> prefer.
> >>
> > Why do you prefer this?
>
> Because the main purpose of aligned_storage<> is to postpone its
> construction?
>
No.
The main purpose is to represent _raw_ aligned storage.
Storage byt itself is orthogonal to object state
(and construction is about _state_ initialization).
Just like operator new returns a 'storage' (i.e, a raw aligned memory
block),
but construction must occur afterwards and independetly
of the storage allocation, aligned_storage also gives you
a raw aligned memory block and is also independent of object construction.

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

>
> >>>> - Maybe we could create 2 separate type lists if optional<> is used
> >>>> many times in the same object, gathering m_initialized types and
> >>>> m_storage in separate lists:
> >>>>
> >>> What for ?
> >>
> >> I think bool arrays use bitfields
> >>
> > Which bool arrays?
> >
> > bool x[..] ;
> >
> > dont't.
> >
> > std::vector<bool>
> >
> > maybe, but are less efficient in that case.
>
> I guess boost::array<bool, size_t> is also optimized...?
>
No, it isn't.
But anyway, remember that bit-allocation _necesarily_
optimizes size at the expense of speed.
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.

Fernando Cacciola