I certainly hope the type is not int _now_! It should be uint, and there's an argument for it being ulong, although that's perhaps only in D-64.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c96nrd$anp$1@digitaldaemon.com...
> Incidently (and again, this is only a semi-serious suggestion, and I don't care if anyone floors this with a rational argument), is there any reason why the type of the sizeof property has to be int for every type?
>
> I mean, bit.sizeof were to return a float instead of an int, then it could return its conceptual size of 0.125 bytes.
>
> (Of course, malloc(float) and similar would then have to be defined to round
up,
> not down!)
>
> Jill
>
>

Arcane Jill wrote:

>Incidently (and again, this is only a semi-serious suggestion, and I don't care
>if anyone floors this with a rational argument), is there any reason why the
>type of the sizeof property has to be int for every type?
>
>I mean, bit.sizeof were to return a float instead of an int, then it could
>return its conceptual size of 0.125 bytes.
>
>(Of course, malloc(float) and similar would then have to be defined to round up,
>not down!)
>
>Jill
>  
>
Floats are allot less efficient to work with then fixed types.


-- 
-Anderson: http://badmama.com.au/~anderson/

>(2) (BUG). The statements:
>
>>       bit b = true;
>>       uint i = -b;
>
>leave i containing the value 0x000000FF. I would have expected
0xFFFFFFFF.

This is because bit is implemented as a byte.

b = 0x01
-b = 0xFF = 255

cast(uint)(-b) = 0x000000FF = 255

The problem is you're using 2's complement arithmetic on unsigned types which doesn't semantically make sense, unless you're intending to use modular arithmetic.

If there were such a thing as a signed byte (there might be for all I know) and you converted it to a signed int with those statements then you would expect to get 0xFFFFFFFF = -1