Get rid of bit and bit[] ?

Kevin Bealer Kevin_member at pathlink.com
Mon Feb 27 01:21:13 PST 2006


In article <dtlst4$2fic$3 at digitaldaemon.com>, Walter Bright says...
>
>
>"Kevin Bealer" <Kevin_member at pathlink.com> wrote in message 
>news:dtjekm$126q$1 at digitaldaemon.com...
>> I think the worst thing would be to have a language designed by the 
>> influence of
>> the people who complained.
>
>LOL. I agree.
>
>> *All* low level programming has to deal with ugly, machine oriented 
>> realities.
>> This will always bother some people.
>
>Yes. D has to work with the reality. Java got into a lot of trouble with 
>floating point because the spec ignored the reality of FPU hardware. The 
>spec got subsequently revised.
>
>> Is "bit" or "bool" one of these?
>
>It turns out that a BitArray struct can pretty much cover nearly all the 
>uses for bit[]. 

I don't use it much in D right now, so this isn't really a request, but as a
related story from C++:

I used vector<bool> in C++ (at work) and discovered that it is much slower to
use vector<bool> than my own vector<int> wrapper, with specialized bit setter /
getter / scanner methods.  I was surprised at this since I thought C++ could /
did override all this stuff for perf. reasons.  (Isn't STL supposed to be a high
performance design?)

The problem in C++ is that all operations over the collection, are defined in
terms of operations with iterators, and vector<bool> doesn't (or can't?) change
this aspect.

For instance, resizing a C++ vector<bool> does a bit-by-bit copy.  So it is
something like 32 times as slow as memcpy(), for a number of common operations.
This affected us, since we were trying to work with vectors of millions of bits,
literally trying to compute ORs and ANDs with bit sets that range up to around a
max of 50 million elements (~6 megabytes).  [D has the operators to do this the
right way, but unfortunately C++ did not.]

One thing I often needed (when I was using vector<bool>), that I don't see in
the D version was a way to scan forward for the next 1 bit.  I would suggest an
interface like this:

ptrdiff_t
BitArray.findValue(size_t start_point, size_t end_point, bool find_this);

Or:

ptrdiff_t
BitArray.findValue(size_t start_point, size_t end_point, BitArray find_this);

Since these interfaces could find values much faster than iteration with
something like opIndex() or opApply().

Kevin





More information about the Digitalmars-d mailing list