Lionello Lunesu wrote:

>>>Oh no, I've started the discussion again? I really didn't mean to.
>>
>>It goes back under the rug then... "Never mind the little bump" :-)
> 
> It's amazing how the bool/string-issue pops up every other week. Walter would just have to hard-code the aliases, just to get it over with :-)

Well, that "sort of" worked for the bool alias ?
(only problem being keywords vs. literals vs. types,
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11757)

The main problem with "alias char[] string;" is
the existance of wchar[]... I suggested "ustring":
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11821

It kinda fits in with the whole int/uint theme of D,
even if "u" here would mean unicode and not unsigned.
(both types are Unicode, but char[] is ascii-biased)

Or maybe "str" and "ustr" would be more orthogonal ?
(keeping with: integer -> int, character -> char, etc)
Just as long as it isn't "String", since that's a class.

> You mean stored as ints? If not, that would be even stranger: bit allocating a byte, but bit[x] allocating at least 4 bytes. Meaning there's a difference between bit and bit[1]. Is bit[1] allowed at all? Is an array of 1 in general allowed? I will test it myself :-)

It's allowed, and it's 4 bytes long. (bit[1])
bit[] is 8 bytes, since it has an int length.

bit[0] is also allowed, and is 0 bytes...
(but that could just be a quirk or bug ?)

> Hmm, lets declare a floating-bit, fbit, and float as fbit[32] :-)

Like a fuzzy boolean. "mostly true", "kinda false"

--anders

Lionello Lunesu wrote:
>>It is faster since you can load/store 32 bits at a time, when setting several. Otherwise it would load/store 8 bits at a time, by using bytes.
> 
> Yeah, but if the array-size is fixed, as is the case with bit[8]? Why would you even want to fetch 32-bits, if you know you only need 8 and fetching a byte is just as fast?

This "hypothetical" 32 bit machine I mentioned earlier, I was actually referring to Pentiums (among others).

So, allocating 32 bits for bit[8] is natural, since allocating a byte
would not generate faster execution: the Pentium fetches all of the
32 bytes anyhow because it just cannot adress memory in smaller chunks.

There are machine code instructions to "load a byte from adress x", etc, but those really load 32 bits, and then throw away the 24 other bits. (The kludges I was talking about.) So C and other programming languages could go on believing they are on a byte-adressable machine.

Since this is the case, the bit-array storage size is rouded up to the nearest 32 bits. Makes writing the compiler easier, generated code faster. And generating the code faster since you don't have to check for bit-array sizes of (less-than-or-equal-to) 8, 16, 24 bits.

(Of course, things get interesting when we end up having 64 bit hardware. This is just one of the issues that has to be dealt with in the 64 bit version of D compiler.)