the bit[] type
Emil Madsen
sovende at gmail.com
Fri Sep 24 02:46:39 PDT 2010
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?
About the bit type, and the bitarray, if I'm interresting in doing anything
alike this, I'm off to allocating an array of chars? - and bitwise accessing
them, to change them?
And now another piece of curiousity, how did this align in memory, would the
compiler couple up bit types, to fill out a byte? - and if so, in how large
a scope would it do this? - current scope?
On 23 September 2010 19:32, bearophile <bearophileHUGS at lycos.com> wrote:
> jcc7:
>
> > As you can see from the links to newsgroup threads at the bottom of the
> first
> > page, the topic was discussed over many years. Perhaps the discussions
> have
> > tapered off in recent years because the current approach is right.
>
> It's an interesting read, thank you (I was present only at the tail of it).
>
> It's a good example of how even an "obviously simple" feature like a
> bool/bit type may hide complexities, design difficulties, requires
> engineering trade-offs, and in the end may produce something with some
> inevitable design defects.
>
> ~bool is forbidden, but in DMD a bool is represented with 8 bits, so it has
> 255 ways to be true and 1 to be false. A boolean like this:
>
> bool b = void;
>
> May contain something different from 0 or 1, this may cause some surprise.
>
> In those discussions I have seen Walter against the usage of bool as return
> type for opEquals, because a cast(bool)some_int is equivalent to:
> n ? 1 : 0
> That requires some instructions, so it isn't fully efficient.
>
> In the pages (operatoroverloading.html and hash-map.html) about the D2
> language I have seen different signatures for the struct opEquals, so I may
> add a little documentation bug report about it:
> int opEquals(ref const S s);
> const bool opEquals(ref const KeyType s);
>
> P. 258 of TDPL shows a struct opEquals that returns a bool, so I presume
> the efficiency considerations have left space for a more semantically clean
> implementation. Isn't DMD able to optimize away (when inlining is present)
> the slowdown caused by the n?1:0 ?
>
> Bye,
> bearophile
>
--
// Yours sincerely
// Emil 'Skeen' Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20100924/67490f98/attachment.html>
More information about the Digitalmars-d-announce
mailing list