the bit[] type

[Emil Madsen]

I know that I'm able to check the assembly out, or even just write out each
bit, but I'm more interresting in knowing if its the same over more
compilers, aka, if theres given a standard for it.

I really must admit I were really 'happy*', when I read that D1 had the bit
type, and immediately I tried to compile a D2 program, to check if it had it
bit type, and I must admit, I were somewhat disappointed, because I think
the bit type, should be in the language, not to replace the bool type, but
to be the type it is, for those special cases where you want it. A recent
example where I could have used it, is dragging out data from the CPUID
instruction, wheres currently one will have to do a lot of bitfiddling, it
really could just be replaced with a union alike:
union
{
     int i;
     bit[32] b;
}
Which would allow one, to directly interact and check each bit. I dont know
if I could use bitArray for this matter, by putting it in a union, I havn't
tried, because in C++, you cant do it with a vector, as the vector has a
constructor (which is not allowed within unions (I think its allow in D,
isn't it?)) and because the size of a vector<bool> with 8 elements != 1byte.

And other example where I think the bittype would be valuable is on embedded
systems, where you could be interrested in the bit/speed trade off, I take
that comes with accessing each bit. - and I do know that I could just write
a bittype myself, and do bitwise operations on it, to get the behavior I
wont, my opinion however, is, that it wont ever get as pretty as a native
language bit type.

An other feature with would be really amazing is if the fabulous
arrayslicing feature, was defined for the bittype (dont know if it ever
were), but if it was, this would open up a hole new way of writing actually
readable bitfiddling code.

In my opinion then D should offer both types, wheres bool should be used as
the main bool type, and bit should be this rarely used type, which should be
accessable, when one really wants it and needs it.

Thats my opinion atleast.
Emil 'Skeen' Madsen

*my english isn't really that good, couldn't come up with anything better

On 24 September 2010 11:57, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Friday 24 September 2010 02:46:39 Emil Madsen wrote:
> > Now I'm just curious, how does D represent a bool type as false and true,
> I
> > take it that false is 0b00000000, is true anything but that? - or will
> the
> > compiler make sure, that its always 0b11111111 or would it be 0b00000001?
> > (as 0b11111111 would be -1 if signed) - is there a given standard for
> this,
> > or is this up to the implementer of the compiler?
>
> I believe that when you cast a bool to an integral type, false is *always*
> 0,
> and true is *always* 1. However, when casting an integral type *to* bool,
> any
> non-zero value is true. Whether the compiler bothers to always make the
> actual
> byte value of the bool 0x01 for true when casting to bool, I don't know. If
> you
> want to know for sure, I believe that you'll have to look at the generated
> assembly code.
>
> - Jonathan M Davis
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20100924/8abb574f/attachment.html>