From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-02-25 22:08:36
Fernando Cacciola wrote:
> 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.
I've just generated some code, and the compiler can even optimize more when
the parameter of operator  is compile-time constant:
0x8048606 <main+6>: movsbl 0xffffffff(%ebp),%eax
0x804860a <main+10>: shr $0x3,%eax
0x804860d <main+13>: add $0xfffffff8,%esp
0x8048610 <main+16>: and $0x1,%eax
The only thing that would not be portable up to now is the number of bits in
a char (8). I do not wish to include assembler code directly, what I meant
was the "generated" machine code by the compiler.
>>> 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
>> other and will not waste any space between themselves.
> Yes, though I still can't see if this would be _needed_.
Well boost::type_with_alignment<> would be more meaningful in optional<>.
Also I am pretty sure the number of optional<> instances will be greater
than 1. Placement operator new will be able to deal with external
I have to take a break... ;)
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