www.digitalmars.com         C & C++   DMDScript  

D - Bit == Boolean??

reply "Luigi" <igiul.reverse email.it> writes:
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!
Sep 08 2002
next sibling parent reply "Dario" <supdar yahoo.com> writes:
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!
Sep 08 2002
parent reply "Dario" <supdar yahoo.com> writes:
 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?
Sep 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Sep 11 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"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.
Sep 12 2002
parent reply "Dario" <supdar yahoo.com> writes:
There is another reason to have a boolean type: a cast from int to bit can
lose the most significant bits.

int a = 10;
bit b = cast(bit) a;

Now b isn't true (as it was expected to be). A boolean type is necessary
which take care of this when casting (explicitly) from a numeric type.
Implicit conversions shouldn't be allowed, or should be allowed only from
bit to bool and vice versa.
Sep 22 2002
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Dario wrote:

 There is another reason to have a boolean type: a cast from int to bit can
 lose the most significant bits.
 
 int a = 10;
 bit b = cast(bit) a;
 
 Now b isn't true (as it was expected to be). A boolean type is necessary
 which take care of this when casting (explicitly) from a numeric type.
 Implicit conversions shouldn't be allowed, or should be allowed only from
 bit to bool and vice versa.


This doesn't work on DMD, but it does on DLI, which always treats bit 
casts as:

    bit b = a ? true : false;

Although faster, of course.  IMO DLI's behaviour is correct.
Sep 22 2002
prev sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Dario" <supdar yahoo.com> wrote in message
news:amkcsh$1isk$1 digitaldaemon.com...

 There is another reason to have a boolean type: a cast from int to bit can
 lose the most significant bits.

 int a = 10;
 bit b = cast(bit) a;

 Now b isn't true (as it was expected to be). A boolean type is necessary
 which take care of this when casting (explicitly) from a numeric type.
 Implicit conversions shouldn't be allowed, or should be allowed only from
 bit to bool and vice versa.


No implicit conversions please. It is similar to having implicit conversion
between "int" and "int*" just because their representation is the same size.
Sep 23 2002
prev sibling parent reply Pavel Minayev <evilone omen.ru> writes:
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!
Sep 12 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Sep 12 2002
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Sep 14 2002
next sibling parent "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
I'd like add a meta-level to Mark's suggestions.  It would be great to be able
to
collect bits strewn across multiple physical hardware locations into a single
item
that may be modified as a whole.  For example, a 48-bit value may be split
across
multiple non-adjacent 32-bit hardware locations.  Being able to collect and
manipulate those bits as a single "thing" would be a dream come true.

Worse yet are strongly inter-related bits strewn across multiple locations.  I'd
prefer to manage them as a set via enum values.  But a single enum value can't
directly work across multiple locations (without explicit user code support). 
If D
did this, I'd be in heaven.

I have also seen hardware that was "expanded" by the manufacturer.  Let's say a
part had a 16-bit internal value that was expanded to 17 bits.  That 17th bit
could
land in any location within the part's address space!  Again, compiler support
would be fantastic.

More and more we embedded programmers need to deal with long bit strings, such
as
are seen in I2C and SPI links, not to mention the behemoth bit collections
present
on any JTAG link.  Describing this structure as a single bit-based entity would
be
invaluable, since no specific mapping to the CPU memory layout would be needed
(or,
more precisely, it would be handled for us by the D compiler).

I would love it if I never had to slice, dice and reassemble another bit stream
ever again.  Getting a bit-stream "almost right" is like being "a little
pregnant".  It's an all-or-nothing proposition.


-BobC



Mark Evans wrote:


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
Sep 15 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Oh, I was trying to avoid bitfields <g>.

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am03uh$a7v$1 digitaldaemon.com...

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
Sep 15 2002
parent reply MicroWizard <MicroWizard_member pathlink.com> writes:
I am glad to see this issue to be discussed again :-)

I'd like to vote on bit fields of arbitrary size.

In D the compiler could change the order of class members which is
completely acceptable (and conceptually clear) while we have to
consider classes (objects) as virtual entities.

In other hand struct members have fixed order and memory footprint since
we could order the compiler how to align these members. Structs are near
to the physical world. So it would be practical to have full control
over the struct layout. That means in a nearest-to-the-iron situation
(embedded controllers, device drivers, even in mixed platforms)
a real struct often has signed and unsigned bitfields, reserved
bits, enumerable numbers (unsigned integers), shifted values, connected
values etc.

These two approaches could live together without pain.

While one designs a system he/she uses virtual building blocks,
for example "objects/entities" whatever convetion we use.
When one implements the system in most every cases he/she must
comply with some existing structure.

The nearest thing to the objects could be a present D class (with interfaces).
The nearest thing to the a physical footprint could be a well behaved struct.

(In the present days I write an XML-like translator which runs on PC and
produces binary output files/streams for embedded controllers (PIC&AVR).
I also have to rewrite an existing timer-executor program which runspresently
on PC, but it should be run on a bigger microcontroller. D would be nice for
these purposes and I use it already, but sometimes I feel it inconvenient.)

I am not sure that C style bit fields are the best implementation, but I feel
the need for a construction like that.

May be Walter could offer an inexpensive or painless alternative.

Handling bits separately is an embedded problem. It would be nice to
describe it with an universal language like D. But it is not the goal
of a 32bit PC compiler to produce bitfield optimized code, I agree.

Best regards,
Tamás Nagy
(microwizard ax.hu)


In article <am1f0s$1mvl$1 digitaldaemon.com>, Walter says...

Oh, I was trying to avoid bitfields <g>.

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am03uh$a7v$1 digitaldaemon.com...

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
Sep 15 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
Bitfields touch on D's charter.  If D wants to be a systems language then it
should have them.  If it wants to be a "32bit PC compiler," then it can live
without.

Either charter is valid, and both together is also valid (my preference!).
Bitfields could be postponed until a later revision (although it is nice to nail
down a spec early).

I liked the suggestion of gathering disparate bits across the system into one
coherent structure.  That is interesting.  The point about a vendor's 16-bit
register growing to 17 bits is answered by arbitrary-length bitfields, which I
mentioned earlier.

Such odd-sized fields would not require structure packing down to the resolution
of one bit.  One-byte resolution is enough.  The 17 bits could fit into a 24-bit
or 32-bit span of memory.  Mainly the compiler must handle naming and accessing
of particular bits (or mini-bit-fields) in some standardized fashion that
eliminates preprocessor macros.  Basically I want to declare a 17-bit register
and give each bit a name and an in-out-both-neither designation ('neither'
applying by default to all out-of-bounds bits above the 17th out of the 24 or 32
allocated).

From an embedded standpoint the key thing is to start the bitfield at precisely
the right hex address (byte resolution here).  This might be a function of the
linker, not the compiler.  Some embedded tools require a "memory map" as an
input to the link step.

The embedded market is pretty huge but the tools are bad.  Typically embedded
development tools are half-baked at best.  I've done lots of C embedded work and
would love to have D at my disposal.  

Mark



 Handling bits separately is an embedded problem. It would be nice to
 describe it with an universal language like D. But it is not the goal
 of a 32bit PC compiler to produce bitfield optimized code, I agree.

 Best regards,
 Tamás Nagy
 (microwizard ax.hu)

Oh, I was trying to avoid bitfields <g>.
Sep 16 2002
parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Mark Evans wrote:


 The embedded market is pretty huge but the tools are bad.  Typically embedded
 development tools are half-baked at best.  I've done lots of C embedded work
and
 would love to have D at my disposal.


That's the nail.  We want D to be the hammer!

Long ago in this newsgroup I described my adventures as a minor participant in
the
EC++ (Embedded C++) standardization effort.  The initial spec was sensational,
and
a couple vendors implemented it, as did GCC.  But the spec didn't evolve as new
ways to make efficient implementations of previously costly C++ features became
available.  EC++ never became more than a "slightly better C", and is now used
only
by Japanese automakers, in conjunction with the uITRON OS (IIRC).

D is well on the path to becoming what EC++ should have been, what C++ itself
could

embedded systems".

I feel it is important to go the extra mile to make it so.

BTW, embedded tools are indeed "half-baked".  They also tend to be quite
expensive,
both to acquire and maintain.  Yet most embedded compiler and tool vendors are
starving (unless you happen to be WindRiver).  Why?  They are all shipping
products
that differ only slightly.  The main differences are who is "first" on a new
processor, and they have to "buy in" with the chip maker to get preferential
early
access.  It is the nature of a "me too" market.

D is a whole new market.

Even if GCC-D takes off like a rocket, there will always be a significant
embedded
market for a complete and supported D tool set.  We're talking about a
significant
income opportunity for Digital Mars here!

But it won't exist if D don't do deep embedded!

And for now, that means a usable volatile and (hopefully) smarter bitfields. 
You
already have reasonably tight code that can get only tighter as the compiler
evolves.

Other features for the embedded market:

1. Choice of output executable format ("naked binary", ELF, COFF, etc.)
2. Integration with other vendors tool suites (WindRiver, iLogix, etc.) and
with as
much of the GNU suite as possible.
3. Targeted to lots and lots and lots and lots and lots and lots of processors!
(Start with ARM, MIPS and SH.)


-BobC
Sep 17 2002
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
Amen to all of that.  D could be the killer app for the embedded market which
still suffers tools that scarcely rise above K&R C...or even assembly.

Aren't the various processors just a back-end issue (though admittedly extra
work)?  Walter might sell back-ends for various chips while the D front-end goes
it merry open-source way.

Happy things to contemplate!

Mark
Sep 17 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3D87FAEE.851E7FF6 users.sourceforge.net...

 Other features for the embedded market:

 1. Choice of output executable format ("naked binary", ELF, COFF, etc.)


Does that matter, or does it matter simply to have a locator that can read
any of those formats?


 2. Integration with other vendors tool suites (WindRiver, iLogix, etc.)


and with as

 much of the GNU suite as possible.
 3. Targeted to lots and lots and lots and lots and lots and lots of


processors!

 (Start with ARM, MIPS and SH.)


Hopefully that will fall out of making GnuD.
Sep 18 2002
prev sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Walter" <walter digitalmars.com> wrote in message
news:als6mv$v08$1 digitaldaemon.com...

 "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.


Bits aren't too useful outside of array of bits. Period.
But booleans are! They just want to be passed as an out parameter. And have
pointers to them. Please make boolean a native type. Do not make the mistake
of C again, by thinking of boolean as an integer. It is similar to lacking
pointers, and using integers for the purpose, just because they are the same
size.

Yours,
Sandor
Sep 16 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
D lacks a native boolean type?  Say it ain't so.  One of the best things that
happened when C became C++ was the native 'bool' type.

Whatever happens with bitfields, a bool type seems an obvious necessity in a
modern language.

Mark
Sep 16 2002
next sibling parent reply Patrick Down <pat codemoon.com> writes:
Mark Evans <Mark_member pathlink.com> wrote in
news:am5lqo$4gd$1 digitaldaemon.com: 


 D lacks a native boolean type?  Say it ain't so.  One of the best
 things that happened when C became C++ was the native 'bool' type.
 
 Whatever happens with bitfields, a bool type seems an obvious
 necessity in a modern language.
 
 Mark


Probably a bool type is a good thing.  However nothing really 
needs to be done to the base compiler to make this happen.  
"typedef byte bool;" works well since D has fixed typedef.  
or "enum bool { true, false }"

It just need to be put into the base phobos distribution so that
there is a common definition.
Sep 16 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns928BC53833945patcodemooncom 63.105.9.61...

 Mark Evans <Mark_member pathlink.com> wrote in
 news:am5lqo$4gd$1 digitaldaemon.com:


 D lacks a native boolean type?  Say it ain't so.  One of the best
 things that happened when C became C++ was the native 'bool' type.

 Whatever happens with bitfields, a bool type seems an obvious
 necessity in a modern language.

 Mark


 Probably a bool type is a good thing.  However nothing really
 needs to be done to the base compiler to make this happen.
 "typedef byte bool;" works well since D has fixed typedef.


A typedef has implicit conversion in one direction. Bool should not have it.


 or "enum bool { true, false }"


I don't want to write:
bool a = bool.true;

So neither is good enough.


 It just need to be put into the base phobos distribution so that
 there is a common definition.
Sep 16 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:am6ij6$11pl$1 digitaldaemon.com...

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns928BC53833945patcodemooncom 63.105.9.61...

 Probably a bool type is a good thing.  However nothing really
 needs to be done to the base compiler to make this happen.
 "typedef byte bool;" works well since D has fixed typedef.


 A typedef has implicit conversion in one direction. Bool should not have


it.

Right.  Not only that, the comparison operators don't produce bool values.


 or "enum bool { true, false }"


 I don't want to write:
 bool a = bool.true;

 So neither is good enough.


Strangely, that's exactly my argument against making enum values have a
scope that's inside the enum name.  We cannot make a user defined enum
that's *not* scope-qualified, and I think that sucks.

Sean
Sep 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:am7njm$2dqf$1 digitaldaemon.com...

 Strangely, that's exactly my argument against making enum values have a
 scope that's inside the enum name.  We cannot make a user defined enum
 that's *not* scope-qualified, and I think that sucks.


It is possible by making them anonymous:

    enum { false, true }
Sep 18 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Ok, awesome!

But then they don't have a distinct type;  at least not one you can access
by name?

Maybe we can make a named enum and then a public accessor for it:

// has to be scope qualified
enum BoolType { false, true };
// anonymous enum with base type of BoolType
enum : BoolType { false = BoolType::false, true = BoolType::true };

Or maybe we could have a way to control whether the enum must be scope
qualified or not.  It would save repetitive cut-n-paste.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:amacma$2amr$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:am7njm$2dqf$1 digitaldaemon.com...

 Strangely, that's exactly my argument against making enum values have a
 scope that's inside the enum name.  We cannot make a user defined enum
 that's *not* scope-qualified, and I think that sucks.


 It is possible by making them anonymous:

     enum { false, true }
Sep 18 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:amadt0$2bu0$1 digitaldaemon.com...

 Ok, awesome!
 But then they don't have a distinct type;  at least not one you can access
 by name?


Correct.


 Maybe we can make a named enum and then a public accessor for it:

 // has to be scope qualified
 enum BoolType { false, true };
 // anonymous enum with base type of BoolType
 enum : BoolType { false = BoolType::false, true = BoolType::true };

 Or maybe we could have a way to control whether the enum must be scope
 qualified or not.  It would save repetitive cut-n-paste.
Sep 18 2002
prev sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:amadt0$2bu0$1 digitaldaemon.com...

 Ok, awesome!

 But then they don't have a distinct type;  at least not one you can access
 by name?

 Maybe we can make a named enum and then a public accessor for it:

 // has to be scope qualified
 enum BoolType { false, true };
 // anonymous enum with base type of BoolType
 enum : BoolType { false = BoolType::false, true = BoolType::true };


No double-colon operator here.
enum : BoolType { false = BoolType.false, true = BoolType.true };

But enums also has implicit conversions with int, hasn't they? And bool
still shouldn't have.
And the problem with the expression is that comparsion still don't yield a
boolean:

void foo(int a) { . }
void foo(BoolType a) { . }

BoolType b = (a > c);  // error
foo(a > c);   // which of the overloaded functions will be called?

Either enum or typedef you still can not create a new distinct type withouth
implicit conversions.
Sep 18 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
OK so long as this technique distinguishes between templated classes with bytes
and bools as the template parameters.  I dislike the enum method, it's just a
shade better than #define TRUE 1.

Maybe the thing to do is revisit the C++ standards committee's decision to
incorporate bools into C++, and see whether the same arguments don't also apply
to D (which is a "better C++").

Mark


In article <Xns928BC53833945patcodemooncom 63.105.9.61>, Patrick Down says...

Mark Evans <Mark_member pathlink.com> wrote in
news:am5lqo$4gd$1 digitaldaemon.com: 


 D lacks a native boolean type?  Say it ain't so.  One of the best
 things that happened when C became C++ was the native 'bool' type.
 
 Whatever happens with bitfields, a bool type seems an obvious
 necessity in a modern language.
 
 Mark


Probably a bool type is a good thing.  However nothing really 
needs to be done to the base compiler to make this happen.  
"typedef byte bool;" works well since D has fixed typedef.  
or "enum bool { true, false }"

It just need to be put into the base phobos distribution so that
there is a common definition.
Sep 17 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I certainly don't think of D so much of as a successor to C++ as it is a
younger sibling rival to it.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am7ri5$2i9d$1 digitaldaemon.com...

 OK so long as this technique distinguishes between templated classes with


bytes

 and bools as the template parameters.  I dislike the enum method, it's


just a

 shade better than #define TRUE 1.

 Maybe the thing to do is revisit the C++ standards committee's decision to
 incorporate bools into C++, and see whether the same arguments don't also


apply

 to D (which is a "better C++").

 Mark
Sep 18 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
You could look at the committee decisions for almost any language and ask why
they support booleans or not, then determine which arguments may apply to D.

I look upon D as an opportunity to "get a language right" and greatly appreciate
Walter's openness to our inputs.  It may well be that he has the correct design
as regards booleans.  I would certainly defer to his judgment as a language
designer.

My input is that I appreciate the standardization offered by a true boolean
type.  Otherwise everyone invents his own boolean, and that game wears a person
out after many years of C.  I've seen TRUE==1, TRUE==0, TRUE==0x01010101,
FALSE==-1, all kinds of weird stuff.

Mark


In article <am9dhi$17js$1 digitaldaemon.com>, Sean L. Palmer says...

I certainly don't think of D so much of as a successor to C++ as it is a
younger sibling rival to it.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am7ri5$2i9d$1 digitaldaemon.com...

 OK so long as this technique distinguishes between templated classes with


bytes

 and bools as the template parameters.  I dislike the enum method, it's


just a

 shade better than #define TRUE 1.

 Maybe the thing to do is revisit the C++ standards committee's decision to
 incorporate bools into C++, and see whether the same arguments don't also


apply

 to D (which is a "better C++").

 Mark
Sep 18 2002
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:amb14m$31a8$1 digitaldaemon.com...

 My input is that I appreciate the standardization offered by a true


boolean

 type.  Otherwise everyone invents his own boolean, and that game wears a


person

 out after many years of C.  I've seen TRUE==1, TRUE==0, TRUE==0x01010101,
 FALSE==-1, all kinds of weird stuff.


D already has true and false defined as keywords, and they resolve to being
expressions of type bit.
Sep 19 2002
prev sibling parent reply "Les Baker" <REMOVETHISlesbaker innova.netREMOVETHIS> writes:
Mark Evans <Mark_member pathlink.com> wrote in message
news:am5lqo$4gd$1 digitaldaemon.com...

 D lacks a native boolean type?  Say it ain't so.  One of the best things


that

 happened when C became C++ was the native 'bool' type.

 Whatever happens with bitfields, a bool type seems an obvious necessity in


a

 modern language.

 Mark


I have really followed this newsgroup and the D language with interest for a
while. I would like to chip in and say that D should have a first-class
boolean type. One thing that I wanted to highlight that was not pointed out
(to my knowledge) was that for me, booleans in C++ help self-document the
code. Right now I am making a class wrapper for win32 controls; a function
prototype like "bool isChecked();" helps make clear what is being returned.
It's just that bool's and bit's are conceptually different when I look at
code. A bool can be a bit, but is a bit always a bool?

An interesting note: even in the D Reference the term "bool" is used instead
of bit some places. See the "Expressions" page, in the discussion about
logical or and logical and operators (for example "The result type of an
OrOr expression is bool").

Just also wanted to encourage Walter and the people using D and making
feedback. It looks like a Good Thing is going on here, and I'm looking
forward to using D. I've unpacked the zip onto my hard drive a while back,
just got to configure the compiler and play around and get some experience
with it.

Les Baker
Sep 20 2002
parent Mark Evans <Mark_member pathlink.com> writes:
That is an excellent point, especially for a language with design-by-contract!
I would not want contracts to return bits, but actual native booleans.

Mark


 for me, booleans in C++ help self-document the
code.
Sep 21 2002
prev sibling parent reply Joe Battelle <Joe_member pathlink.com> writes:
If not, what's it use?


packed/optimized bit vectors (arrays)
Sep 08 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
Sep 11 2002