<div>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.</div><div><br>
</div><div>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:</div>
<div>union</div><div>{</div><div> int i;</div><div> bit[32] b;</div><div>}</div><div>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.</div>
<div><br></div><div>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.</div>
<div><br>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thats my opinion atleast.</div><div>Emil 'Skeen' Madsen</div><div><br></div><div>*my english isn't really that good, couldn't come up with anything better</div><br><div class="gmail_quote">
On 24 September 2010 11:57, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Friday 24 September 2010 02:46:39 Emil Madsen wrote:<br>
> Now I'm just curious, how does D represent a bool type as false and true, I<br>
> take it that false is 0b00000000, is true anything but that? - or will the<br>
> compiler make sure, that its always 0b11111111 or would it be 0b00000001?<br>
> (as 0b11111111 would be -1 if signed) - is there a given standard for this,<br>
> or is this up to the implementer of the compiler?<br>
<br>
</div>I believe that when you cast a bool to an integral type, false is *always* 0,<br>
and true is *always* 1. However, when casting an integral type *to* bool, any<br>
non-zero value is true. Whether the compiler bothers to always make the actual<br>
byte value of the bool 0x01 for true when casting to bool, I don't know. If you<br>
want to know for sure, I believe that you'll have to look at the generated<br>
assembly code.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>// Yours sincerely<br>// Emil 'Skeen' Madsen<br>