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
>> follow
> each
>> 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
initializations also.
I have to take a break... ;)
Philippe A. Bouchard
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
