Don Clugston wrote:
> Walter Bright wrote:
> 
>> I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.
>>
>> Should bit and bit[] be removed before 1.0?
>>
>> There is a place for bit[] as a library type, though.
>>
>> So what do people think? 
> 
> 
> Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own.
> I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.

Can someone explain the vector<bool> problem?  I thought C++'s bool resolved to an integer of the native word size of the machine.

Conceptually, I can't see a problem here, but then again I've not cared to do much C++ coding in a while. =P


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:

> Can someone explain the vector<bool> problem?  I thought C++'s bool resolved to an integer of the native word size of the machine.

It does, but the standard specifies (or at least used to specify) vector<bool> as a specialization that keeps a packed representation internally. This leads to many inconsistencies similar to bit[] in D.

I do not know what the C++ committee has since decided regarding this.

/Oskar

Don Clugston wrote:

> Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own.

Not the "fundamental data type" then ? ;-) Even more confusing was/is
that the bit type in D acts like a boolean - and not like an integer.

I for one won't be sad to see it go... (replacing "bit" with "bool")

> I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.

I'm not sure that switching bool[] over, from bit[] to byte[],
would be that big a "waste", even if it's up to 8 times bigger ?

And like been said earlier, there are plenty of BitArray classes.

--anders

In article <dtmh75$nn1$1@digitaldaemon.com>, Don Clugston says...
>
>Walter Bright wrote:
>> I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.
>> 
>> Should bit and bit[] be removed before 1.0?
>> 
>> There is a place for bit[] as a library type, though.
>> 
>> So what do people think?
>
>Something I didn't see anyone mention is the fact that 'bit' isn't
>really a native CPU type. x86 doesn't have any instructions that operate
>on bits per se, except for the carry flag. Everything else is operations
>on bits within integers. Bits are like quarks: everything is made out of
>them, but you can never see one on its own.
>I think D has been pretending that there's such a thing as an isolated
>bit, the same mistake that C++ made with vector<bool>. It's an illusion
>that's too costly to maintain.

Good point.

I'd even go as far to say that even for embedded micro-controllers (like Microchip PICs for example), I/O pins are managed as groups of 4, 8 or 16 to a 'port' at the assembler code level. So the bit[] paradigm wouldn't be a big gain for that paradigm even though you wind up manipulating individual bits a fair amount.

The only thing that bit[] had going for it was the potential for iteration via foreach().  Since most uses of bit[] would map well to a single uint or ulong, you can cover the bases with good old-fashioned flags, at the cost of some minor syntax and value changes (powers-of-two versus bit indexing).

- Eric Anderton

In article <dtlvp3$2isk$1@digitaldaemon.com>, Sean Kelly says...
>
>Kevin Bealer wrote:
>> 
>> But I think 80% of user complaints are driven not by real design motivations, but by the "surprise" principle:  "Why doesn't it work the way I guessed it would?"
>
>There's something to be said for predictability.  It doesn't have to be a slippery slope :-)

I've thought about this more, and I mostly agree... But there are several reasons for such predictions.  These come to mind:

A. My other language does X.
B. Java, C or C++ does X (special case, as these are sort of 'siblings' to D,
at least in the mind of users.
C. Mathematicians do X.
D. D does X in this other part over here.
E. WWDEKD? What would Donald E. Knuth do? :)
F. I just expected it out of the blue - I've never programmed before.
G. I just expected it out of the blue - I worked in assembler for years.

(A) and (C) are not important to me.  The (D) variant is the most important to
me.  (F) is semi-important but is the "web page" level of design, not great for
systems languages.  (G) is relevant for performance and hardware interfacing
cases especially.

(B) is relevant, but most of what we argue varies between Java, C, and C++, so
what we see is often (B) vs. (B), argued from different sides.

(E) is a religious question, as always... ;)

Kevin

>> This principle makes perfect sense at the high level (web page) but not at the hardware level.  Software can be beautiful, but not "too beautiful for this world".  If D gets the low level stuff right, it *has* to have ugly parts that are fast a la C rather than pretty parts that are slow al la Java, in at least a few, unremovable cases.
>> 
>> Is "bit" or "bool" one of these?
>
>I don't think so.  I find that the inability to address array-stored bits causes me more trouble than is worth the benefits.  Particularly considering that an equivalent library class could be created which provides similar performance characteristics.
>
>
>Sean

In article <dtlst4$2fic$3@digitaldaemon.com>, Walter Bright says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dtjekm$126q$1@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

Kevin Bealer wrote:
> (E) is a religious question, as always... ;)

He ain't dead yet.