I have a simple thing: bit is equal to boolean type?

If not, what's it use?

Thank you

--
Luigi
--
void f (OS x) {while (x.getbugs() > 0); destroy(earth);};
f (windows); // Meno male!

Yes, it is.
'bit' is a special type, particularly useful to optimize arrays, but has
some limitations (e.g. you can't get its address, since a bit has no address
in most architectures).

Someone suggested that 'bit' should be an arithmetic type, and 'bool' should be added to the language as a boolean type. Anyway nobody needed an arithmetic bit and everybody always used 'bit' as a boolean. So the idea seems to be discarded. 'bit' actually is the official D boolean type.

I noticed that Walter used 'int' as the return value for all ctype.d's functions. Maybe he'll change them to 'bit' in the future (it's a consistency matter).

> I have a simple thing: bit is equal to boolean type?
>
> If not, what's it use?
>
> Thank you
>
> --
> Luigi
> --
> void f (OS x) {while (x.getbugs() > 0); destroy(earth);};
> f (windows); // Meno male!
>
>

>If not, what's it use?
packed/optimized bit vectors (arrays)

> Yes, it is.
> 'bit' is a special type, particularly useful to optimize arrays, but has
> some limitations (e.g. you can't get its address, since a bit has no
address
> in most architectures).

Uh, it seems to work.
'bit*' works well, but we still don't have out bit parameters.
What does this mean, Walter?

"Dario" <supdar@yahoo.com> wrote in message news:ali67b$1r5n$1@digitaldaemon.com...
> > Yes, it is.
> > 'bit' is a special type, particularly useful to optimize arrays, but has
> > some limitations (e.g. you can't get its address, since a bit has no
> address
> > in most architectures).
> Uh, it seems to work.
> 'bit*' works well, but we still don't have out bit parameters.
> What does this mean, Walter?

There's no simple way to take the address of a bit, and out parameters are implemented as pointers.

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:alh74a$1clf$1@digitaldaemon.com...
> >If not, what's it use?
> packed/optimized bit vectors (arrays)

For an example, check out the gc implementation.

"Walter" <walter@digitalmars.com> wrote in message news:alpatj$2ip3$1@digitaldaemon.com...
>
> "Dario" <supdar@yahoo.com> wrote in message news:ali67b$1r5n$1@digitaldaemon.com...
> > > Yes, it is.
> > > 'bit' is a special type, particularly useful to optimize arrays, but
has
> > > some limitations (e.g. you can't get its address, since a bit has no
> > address
> > > in most architectures).
> > Uh, it seems to work.
> > 'bit*' works well, but we still don't have out bit parameters.
> > What does this mean, Walter?
>
> There's no simple way to take the address of a bit, and out parameters are implemented as pointers.

I see that as an argument for separate a boolean type.

Walter wrote:

> There's no simple way to take the address of a bit, and out parameters are
> implemented as pointers.

Just as bit arrays have separate implementation, so should do bit out
parameters. Of course it will be more than just a pointer, but why
should I care about it when I write code? bit shouldn't be lower-level
than other types are, and out parameters are fundamental language
construct. No pointers to bits sounds okay simply because pointers
are too low-level themselves, but out parameters aren't restricted
(or even specified) to be pointers!

"Pavel Minayev" <evilone@omen.ru> wrote in message news:alpvua$9jt$1@digitaldaemon.com...
> Walter wrote:
> > There's no simple way to take the address of a bit, and out parameters
are
> > implemented as pointers.
> Just as bit arrays have separate implementation, so should do bit out parameters. Of course it will be more than just a pointer, but why should I care about it when I write code? bit shouldn't be lower-level than other types are, and out parameters are fundamental language construct. No pointers to bits sounds okay simply because pointers are too low-level themselves, but out parameters aren't restricted (or even specified) to be pointers!

In general, you're right. But I tend to think bits aren't too useful outside of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.

>
>In general, you're right. But I tend to think bits aren't too useful outside of arrays of bits, and so aren't worth the extra definitional and implementation effort. This is one area where I'd like to see how things evolve.
>

Walter,

Yes arrays of bits are useful!  Anything to enhance the construction and use of bit-flags fields would be nice.

The error-prone process of writing C preprocessor macros is a pain.  All that bit shifting and masking takes forever to get right.  How nice it would be for the language to offer direct constructs.

I'd like specific keywords and language constructs for bitfields.  In particular, bitfields of arbitrarily large size.  They can be multiples of some integer size, but the point is to allow bitfields which exceed the size of one standard integer.  Say, a bitfield with 256 bits.

Bitfields sometimes mix numbers with boolean bits, and the numbers can have arbitrary bit-sizes.  Two bits gives integers 0-3, etc.  This number sits between boolean bits in a common bitfield.

For a language that aspires to be a systems language, these features would sure be cool.

Come to that, what about hardware registers?  The D design-by-contract philosophy could be applied here.  Sometimes a register is read-only, sometimes write-only, and sometimes read-write.  Just depends on the hardware.  Sometimes a register may have a size not matching a multiple of some integer.  D should handle that.

For example, I might have a register 8 bits wide which serves one major function in bits 0-2 and another entirely different function in bits 3-7.  The problem is all the masking to ensure that I don't hit 0-2 while exercising 3-7.  A systems language permitting me to define separate bit fields for these ranges would be a dream.

Mark