www.digitalmars.com         C & C++   DMDScript  

D - No out bit parameters

reply Frank Wills <fdwills sandarh.com> writes:
No out bit parameters: I can work
around this, but I was curious about
the reason. Is it just technical?

I like to have certain functions
return a bit value for success or
failure, and use an out parameter
to return results.

bit someFunc(out char[] result)
but
bit someFunc(out bit result)
isn't allowed.
Aug 03 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Frank Wills wrote:
 No out bit parameters: I can work
 around this, but I was curious about
 the reason. Is it just technical?

I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte. Obviusly, it is not requiered for an out parameter... Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet. -i.
Aug 03 2003
next sibling parent Frank Wills <fdwills sandarh.com> writes:
Actually, my workaround is to use a pointer
to a bit as the parameter, which works fine.

Ilya Minkov wrote:
 Frank Wills wrote:
 
 No out bit parameters: I can work
 around this, but I was curious about
 the reason. Is it just technical?

I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte. Obviusly, it is not requiered for an out parameter... Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet. -i.

Aug 03 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bgjbv6$2ll9$1 digitaldaemon.com...
 Walter: how about allowing pointer to bit in an abridged form? It can
 currently be a simple byte pointer, which you get when taking adress of
 a bit, but when the bit is not lowest within a byte, it should raise an
 exception, signalling that it's not implemented yet.

Yes, that is a good idea.
Aug 03 2003
parent reply Frank Wills <fdwills sandarh.com> writes:
Walter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:bgjbv6$2ll9$1 digitaldaemon.com...
 
Walter: how about allowing pointer to bit in an abridged form? It can
currently be a simple byte pointer, which you get when taking adress of
a bit, but when the bit is not lowest within a byte, it should raise an
exception, signalling that it's not implemented yet.

Yes, that is a good idea.

is the answer too "obvious" to answer?
Aug 03 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Frank Wills" <fdwills sandarh.com> wrote in message
news:bgjlhl$2ts2$1 digitaldaemon.com...
 Walter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:bgjbv6$2ll9$1 digitaldaemon.com...
Walter: how about allowing pointer to bit in an abridged form? It can
currently be a simple byte pointer, which you get when taking adress of
a bit, but when the bit is not lowest within a byte, it should raise an
exception, signalling that it's not implemented yet.


is the answer too "obvious" to answer?

The trouble comes from the out parameter being one bit out of an array of bits. Then, a simple pointer will no longer suffice, it needs a pointer and a bit number. It's not impossible, just some more work to implement.
Aug 03 2003
parent Frank Wills <fdwills sandarh.com> writes:
Walter wrote:
 
 The trouble comes from the out parameter being one bit out of an array of
 bits. Then, a simple pointer will no longer suffice, it needs a pointer and
 a bit number. It's not impossible, just some more work to implement.
 

Ok, thanks. I was just curious as to why it was that way, and also trying to help by providing feedback. I don't know if you intended bit pointers to be used, or to work at this point, but they do, and that is what I am using until the bit type is usable with an out parameter, which is more elegant to use that pointers.
Aug 03 2003
prev sibling parent Frank Wills <fdwills sandarh.com> writes:
Ilya Minkov wrote:
 Frank Wills wrote:
 
 No out bit parameters: I can work
 around this, but I was curious about
 the reason. Is it just technical?

I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte. Obviusly, it is not requiered for an out parameter...

Why do you say "obviously" it is not required as an out parameter? I don't see anything "obvious" about what you say at all.
 Walter: how about allowing pointer to bit in an abridged form? It can 
 currently be a simple byte pointer, which you get when taking adress of 
 a bit, but when the bit is not lowest within a byte, it should raise an 
 exception, signalling that it's not implemented yet.
 
 -i.
 

Aug 03 2003
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
which bit is the bit ?
consider;
void func( out bit rv, int i ) { ... }
void meth() {
    bit a,b, c;
    func(a, 0 );func(b, 3 );func(c, 6 );
}
a,b,c might be bits 0,1,2 of the first stack word
shift and mask to the in is always bit0 is o.k.
but you either have to pass the ptr to the storage word/dword and the
position to save to
or have copy on return (which might mess up some code).
I believe there is no bit*
which would be struct ( int pos, int * storePtr; } similar to array.

"Frank Wills" <fdwills sandarh.com> wrote in message
news:bgiv3n$2ati$1 digitaldaemon.com...
 No out bit parameters: I can work
 around this, but I was curious about
 the reason. Is it just technical?

 I like to have certain functions
 return a bit value for success or
 failure, and use an out parameter
 to return results.

 bit someFunc(out char[] result)
 but
 bit someFunc(out bit result)
 isn't allowed.

Aug 03 2003
parent reply Frank Wills <fdwills sandarh.com> writes:
Mike,

Sure, sure, yes, yes, I imagine that most
people on this list understand everything you
are explaining, and the issues involved
(who on this list doesn't know what a bit is,
and that it is a part of a larger addressable
unit in memory?)

I just wanted to know (from Walter):
  1) Why "out" isn't currently implemented for
bit parameters.
  1 - Walter's answer) It sounds like it will or
could be, if and when he gets to it. And that
there's just more work to implementing the bit
type in various manners. Obviously there are
no 'bit' addressable memory units in memory,
it must be 'extracted' from larger units (I'm
not telling anyone anything new here am I?)

  2) Bit pointers __do__ currently work. Does
Walter __intend__ for them to work, or are
they just happening to work.
  2 - Walter's answer) It sounds like he may
do something to better refine the use of
bit pointers. I don't yet know if he intended
for them to work at this point at all.

Mike Wynn wrote:
 which bit is the bit ?
 consider;
 void func( out bit rv, int i ) { ... }
 void meth() {
     bit a,b, c;
     func(a, 0 );func(b, 3 );func(c, 6 );
 }
 a,b,c might be bits 0,1,2 of the first stack word
 shift and mask to the in is always bit0 is o.k.
 but you either have to pass the ptr to the storage word/dword and the
 position to save to
 or have copy on return (which might mess up some code).
 I believe there is no bit*
 which would be struct ( int pos, int * storePtr; } similar to array.
 
 "Frank Wills" <fdwills sandarh.com> wrote in message
 news:bgiv3n$2ati$1 digitaldaemon.com...
 
No out bit parameters: I can work
around this, but I was curious about
the reason. Is it just technical?

I like to have certain functions
return a bit value for success or
failure, and use an out parameter
to return results.

bit someFunc(out char[] result)
but
bit someFunc(out bit result)
isn't allowed.


Aug 03 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Wearing my heretical pragmatist hat, may I pose the question: why do we have
a bit type? I am at a loss to think why it is useful (or more useful than
bit fields).

I'll concede that I've not done any comms programming for some time, so
maybe the "totally bleeding obvious" reason has slipped my memory.

Yours, ready to be informed

Matthew

"Frank Wills" <fdwills sandarh.com> wrote in message
news:bgk5n1$bs2$1 digitaldaemon.com...
 Mike,

 Sure, sure, yes, yes, I imagine that most
 people on this list understand everything you
 are explaining, and the issues involved
 (who on this list doesn't know what a bit is,
 and that it is a part of a larger addressable
 unit in memory?)

 I just wanted to know (from Walter):
   1) Why "out" isn't currently implemented for
 bit parameters.
   1 - Walter's answer) It sounds like it will or
 could be, if and when he gets to it. And that
 there's just more work to implementing the bit
 type in various manners. Obviously there are
 no 'bit' addressable memory units in memory,
 it must be 'extracted' from larger units (I'm
 not telling anyone anything new here am I?)

   2) Bit pointers __do__ currently work. Does
 Walter __intend__ for them to work, or are
 they just happening to work.
   2 - Walter's answer) It sounds like he may
 do something to better refine the use of
 bit pointers. I don't yet know if he intended
 for them to work at this point at all.

 Mike Wynn wrote:
 which bit is the bit ?
 consider;
 void func( out bit rv, int i ) { ... }
 void meth() {
     bit a,b, c;
     func(a, 0 );func(b, 3 );func(c, 6 );
 }
 a,b,c might be bits 0,1,2 of the first stack word
 shift and mask to the in is always bit0 is o.k.
 but you either have to pass the ptr to the storage word/dword and the
 position to save to
 or have copy on return (which might mess up some code).
 I believe there is no bit*
 which would be struct ( int pos, int * storePtr; } similar to array.

 "Frank Wills" <fdwills sandarh.com> wrote in message
 news:bgiv3n$2ati$1 digitaldaemon.com...

No out bit parameters: I can work
around this, but I was curious about
the reason. Is it just technical?

I like to have certain functions
return a bit value for success or
failure, and use an out parameter
to return results.

bit someFunc(out char[] result)
but
bit someFunc(out bit result)
isn't allowed.



Aug 03 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Matthew Wilson wrote:

 Wearing my heretical pragmatist hat, may I pose the question: why do we have
 a bit type? I am at a loss to think why it is useful (or more useful than
 bit fields).

Its semantics are for boolean. It should be renamed - I want "boolean", as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?
Aug 03 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgkdol$ish$1 digitaldaemon.com...
 Matthew Wilson wrote:

 Wearing my heretical pragmatist hat, may I pose the question: why do we


 a bit type? I am at a loss to think why it is useful (or more useful


 bit fields).

Its semantics are for boolean. It should be renamed - I want "boolean", as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

I could not agree more. It should be called boolean, it should not be a bit, it should be the same size as int, and any writing of the literal 'true' in (sub-)expressions should be automatically translated by the compiler to the inverse expression involving 'false', thereby avoiding the potential dangers of tri-state bool in C++. Furthermore, (now you've got me going!), all conditional (sub-)expression should have to be _explicitly_ boolean. Hence boolean b; int i; if( b && i) // compiler error {} if( b && i != 0) // ok {} But I realise that all the obfuscators will *never* swallow that one, so just give me the first paragraph of requirements above, and I'll be quiet. Matthew
Aug 03 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgkeft$jk9$1 digitaldaemon.com...
 It should be called boolean, it should not be a bit, it should be the same
 size as int, and any writing of the literal 'true' in (sub-)expressions
 should be automatically translated by the compiler to the inverse

 involving 'false', thereby avoiding the potential dangers of tri-state

 in C++.

Maybe it could be a "real" bit when it's an element in an array. Once you have the starting address and index, automatic bit masking is not that hard to implement. Besides, why not make it 1 byte in size, or at least have a compiler option which lets you do it?
 Furthermore, (now you've got me going!), all conditional (sub-)expression
 should have to be _explicitly_ boolean. [...]

I see the point. That's going to be a hard battle though... Ric
Aug 04 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgkdol$ish$1 digitaldaemon.com...
 Matthew Wilson wrote:
 Wearing my heretical pragmatist hat, may I pose the question: why do we


 a bit type? I am at a loss to think why it is useful (or more useful


 bit fields).

as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way. "bool" is used in C and C++.
Aug 04 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bglv4d$1vvn$2 digitaldaemon.com...
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgkdol$ish$1 digitaldaemon.com...
 Matthew Wilson wrote:
 Wearing my heretical pragmatist hat, may I pose the question: why do



 have
 a bit type? I am at a loss to think why it is useful (or more useful


 bit fields).

as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way. "bool"

 used in C and C++.

symantics) the Java boolean is what we want (I do): storage and implementation are undefined only the semantics are defined. it can be only true or false, and if cast to a numeric value then false === 0 true === 1 (like C where !!int is 0 or 1 ) to cast a pointer or reference (object or array) to boolean is equiv to b = (o === null) ? false : true; all compare ops return they type boolean not bit. I've no objection to bit and bit[] (although think if you have them then they should be complete [that is int to bit array and bit array slice to int operations, along with inout, out and pointer to bit]) I have the same "problem" with char/wchar[] as strings to me string is a concept and char[] implementation.
Aug 04 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgkdol$ish$1 digitaldaemon.com...
 
Matthew Wilson wrote:

Wearing my heretical pragmatist hat, may I pose the question: why do we


have
a bit type? I am at a loss to think why it is useful (or more useful


than
bit fields).

Its semantics are for boolean. It should be renamed - I want "boolean", as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way. "bool" is used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
Aug 04 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgmfml$2fr1$1 digitaldaemon.com...
 I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
 there is the implication that there is none of this tri-state confusion
 nonsense we find in C, but others obviously don't see it that way.


 used in C and C++.

comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.
Aug 04 2003
next sibling parent reply BenjiSmith <BenjiSmith_member pathlink.com> writes:
I think that a 'bit' gives the impression that it will always be implemented as
one element of an eight-element byte. That's the impression that I get from
using a 'bit'. I don't know if that's how it's implemented in DMD, but that's
how I think of it: as a tiny unit of memory.

Now, a 'boolean' is not a unit of memory as all. It's a semantic term given to a
true/false condition. I don't care how a boolean is implemented, as long as it
has two-and-only-two values: true and false, and as long as it provides me a
mechanism for flipping between the two values.

If you're a compiler vendor (and you are), I don't care whether you implement
the boolean primitive type as a bit or as an 8-bit type, if that makes
addressing and dereferencing more efficient. Let the compiler do whatever it
wants with boolean types as long as I can get sizeof(boolean) to know how many
bits (or bytes) are taken up by the type. However, if I call sizeof(bit), it
should be exactly the same on every platform (.125).

I don't know if anybody else is on the same page as me, but these are the
reasons that I'd like to have a boolean type instead of just a bit type. Of
course, I'd like to have _both_ bits and booleans (please just don't call it
'bool'), since bits (and bit arrays) could be useful for their own purposes. But
I'd prefer to keep my true/false values in a boolean than in a bit.

In article <bgmnb5$2n2b$1 digitaldaemon.com>, Walter says...
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgmfml$2fr1$1 digitaldaemon.com...
 I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
 there is the implication that there is none of this tri-state confusion
 nonsense we find in C, but others obviously don't see it that way.


 used in C and C++.

comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

Aug 04 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"BenjiSmith" <BenjiSmith_member pathlink.com> wrote in message
news:bgmpoe$2ph4$1 digitaldaemon.com...
 I think that a 'bit' gives the impression that it will always be

 one element of an eight-element byte. That's the impression that I get

 using a 'bit'. I don't know if that's how it's implemented in DMD, but

 how I think of it: as a tiny unit of memory.

'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the rest of the byte is unused.
 Now, a 'boolean' is not a unit of memory as all. It's a semantic term

 true/false condition. I don't care how a boolean is implemented, as long

 has two-and-only-two values: true and false, and as long as it provides me

 mechanism for flipping between the two values.

'bit' does that.
 If you're a compiler vendor (and you are), I don't care whether you

 the boolean primitive type as a bit or as an 8-bit type, if that makes
 addressing and dereferencing more efficient. Let the compiler do whatever

 wants with boolean types as long as I can get sizeof(boolean) to know how

 bits (or bytes) are taken up by the type. However, if I call sizeof(bit),

 should be exactly the same on every platform (.125).

'bit' does that, too. bit.size will give (1), because unless it is an array of bits, it is put into a byte.
 I don't know if anybody else is on the same page as me, but these are the
 reasons that I'd like to have a boolean type instead of just a bit type.

 course, I'd like to have _both_ bits and booleans (please just don't call

 'bool'), since bits (and bit arrays) could be useful for their own

 I'd prefer to keep my true/false values in a boolean than in a bit.

I just fail to see what improvement boolean has over bit. Also, what's wrong with 'bool'? It fits with the C'ish convention of using 'int' instead of 'integer', 'float' instead of 'floatingpointreal', etc.
Aug 04 2003
next sibling parent reply Derek Parnell <derek.parnell no.spam> writes:
On Mon, 4 Aug 2003 18:34:51 -0700 (08/05/03 11:34:51)
, Walter <walter digitalmars.com> wrote:

 "BenjiSmith" <BenjiSmith_member pathlink.com> wrote in message
 news:bgmpoe$2ph4$1 digitaldaemon.com...
 I think that a 'bit' gives the impression that it will always be

 one element of an eight-element byte. That's the impression that I get

 using a 'bit'. I don't know if that's how it's implemented in DMD, but

 how I think of it: as a tiny unit of memory.

'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the rest of the byte is unused.
 Now, a 'boolean' is not a unit of memory as all. It's a semantic term

 true/false condition. I don't care how a boolean is implemented, as long

 has two-and-only-two values: true and false, and as long as it provides 
 me

 mechanism for flipping between the two values.

'bit' does that.
 If you're a compiler vendor (and you are), I don't care whether you

 the boolean primitive type as a bit or as an 8-bit type, if that makes
 addressing and dereferencing more efficient. Let the compiler do 
 whatever

 wants with boolean types as long as I can get sizeof(boolean) to know 
 how

 bits (or bytes) are taken up by the type. However, if I call sizeof(bit) 
 ,

 should be exactly the same on every platform (.125).

'bit' does that, too. bit.size will give (1), because unless it is an array of bits, it is put into a byte.
 I don't know if anybody else is on the same page as me, but these are 
 the
 reasons that I'd like to have a boolean type instead of just a bit type.

 course, I'd like to have _both_ bits and booleans (please just don't 
 call

 'bool'), since bits (and bit arrays) could be useful for their own

 I'd prefer to keep my true/false values in a boolean than in a bit.

I just fail to see what improvement boolean has over bit. Also, what's wrong with 'bool'? It fits with the C'ish convention of using 'int' instead of 'integer', 'float' instead of 'floatingpointreal', etc.

Its a conceptual thing mainly. A 'bool' is a STATE but a 'bit' holds a data value. A 'bit' must be mapped to a RAM location but a 'bool' doesn't (I'm not talking about implementatin here - just logical/conceptual stuff). Conceptually, you can do arithmetic with bits but it doesn't make sense to add up three 'bools', for example. When it comes to implementing a bool, you would probably wise to choose a data storage element that is fast - such as an int. However, you might serious consider disallowing arithmetic functionality, include comparisions to numeric values. It doesn't make much sense if test if a 'bool' is larger than 5, for example. As you mention above, a 'bit' can be used to implement a 'bool'. However, a 'bit' has more functionality behind it than a 'bool' needs or even wants. -- Derek
Aug 04 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Derek Parnell" <derek.parnell no.spam> wrote in message
news:oprtesn7jf59ej19 news.digitalmars.com...
 Its a conceptual thing mainly. A 'bool' is a STATE but a 'bit' holds a

 value. A 'bit' must be mapped to a RAM location but a 'bool' doesn't (I'm
 not talking about implementatin here - just logical/conceptual stuff).

That's just not true. There is nothing that says a bit has to be in a memory location: It could just as easily dwell in a register or even in a CPU flag, if only transiently.
 Conceptually, you can do arithmetic with bits but it doesn't make sense to
 add up three 'bools', for example.

True enough, the operators that apply to bool are different than the ones that apply to bit. Logical ops could apply to both. Seems the main difference is that bit is compatible mathematically with integers, and bool is not. However if you think about it, AND is alot like multiply or minimum, OR is alot like maximum, XOR is alot like addition or subtraction. One could define operations that make sense on both. It would take great care to do so, however, and probably people would end up confused.
 When it comes to implementing a bool, you would probably wise to choose a
 data storage element that is fast - such as an int. However, you might
 serious consider disallowing arithmetic functionality, include

 to numeric values. It doesn't make much sense if test if a 'bool' is

 than 5, for example.

 As you mention above, a 'bit' can be used to implement a 'bool'. However,

 'bit' has more functionality behind it than a 'bool' needs or even

  Derek

Yep, that pretty much sums it up. Sean
Aug 08 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bgn1bu$30od$1 digitaldaemon.com>, Walter says...
 how I think of it: as a tiny unit of memory.

'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the rest of the byte is unused.

sorry, to embedded folks that's a little confusing. we want a bit to be one part of a register or memory location which may be combined together in contiguous but odd or even sizes (the hardware guys never like to waste bits by padding out) to control all sorts of stuff. 0 5 12 31 | field_1 | field_2 | field_3 | If D is supposed to be a systems programming language than it shouldn't confuse the hardware engineers who create the FPGAs which in turn are manipulated by the embedded SW folks.
Aug 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bgo4e1$111h$1 digitaldaemon.com...
 In article <bgn1bu$30od$1 digitaldaemon.com>, Walter says...
 how I think of it: as a tiny unit of memory.

'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and


rest of the byte is unused.

sorry, to embedded folks that's a little confusing. we want a bit to be

 of a register or memory location which may be combined together in

 but odd or even sizes (the hardware guys never like to waste bits by

 out) to control all sorts of stuff.

 0         5            12                       31
 | field_1 | field_2    |        field_3         |

 If D is supposed to be a systems programming language than it shouldn't

 the hardware engineers who create the FPGAs which in turn are manipulated

 embedded SW folks.

I've actually done code dealing with such issues (and I've even written FPGA design tools), and I find it works best to simply write the shift and mask operations custom to the job.
Aug 05 2003
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
Walter wrote
I've actually done code dealing with such issues (and I've even written FPGA
design tools), and I find it works best to simply write the shift and mask
operations custom to the job.

Oh my goodness - those are one of the major bug nests in embedded work. How nice it would be to just 'slice' a bit array instead. About the boolean type I would not mind its absence if D were not a DbC language. But in such a language, the missing boolean type is like a missing thumb. Since DbC is built into the language, booleans should be built into it as well - they go together. C/C++ doesn't have DbC so it's a different story. Mark
Aug 06 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bgpbmc$29go$1 digitaldaemon.com...
 I've actually done code dealing with such issues (and I've even written

 design tools), and I find it works best to simply write the shift and mask
 operations custom to the job.

Please. You should know better than anyone that a compiler is far more suited to that task than any person. It's tedious, error-prone grunt work, and nobody should have to do that anymore. It's 2003, not 1970. ;) Besides, explicit bit masking is *UGLY*, and deserves to be hidden behind the scenes. Sean
Aug 08 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"BenjiSmith" <BenjiSmith_member pathlink.com> wrote in message
news:bgmpoe$2ph4$1 digitaldaemon.com...
 I don't know if anybody else is on the same page as me, but these are the
 reasons that I'd like to have a boolean type instead of just a bit type.

 course, I'd like to have _both_ bits and booleans (please just don't call

 'bool'), since bits (and bit arrays) could be useful for their own

 I'd prefer to keep my true/false values in a boolean than in a bit.

FWIW, I prefer the shortened name 'bool'. For one thing, that's what C and C++ people will expect, and what they're used to. Gives D a bit more compatibility with those languages. It's the same reason we don't write out 'integer' ala Pascal. When you write 'int' everyone knows what you mean, and it's shorter to type. D is derived from C, not Pascal, and it should stick closer to C conventions unless there are good reasons to stray. Sean
Aug 08 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bgvmgb$25ko$1 digitaldaemon.com...
 D is derived from C, not Pascal, and it should stick closer to C

 unless there are good reasons to stray.

Yes, exactly.
Aug 09 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bh4nql$qhm$3 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bgvmgb$25ko$1 digitaldaemon.com...
 D is derived from C, not Pascal, and it should stick closer to C

 unless there are good reasons to stray.

Yes, exactly.

to stick close to C bool is stored in int (where int is the most efficient memory operand size no shorter than a short and no longer than a long) which means short on 68k (16 bit bus), int on x86 and I guess short or int on Arm depending on the machine etc and so on) and its not a bit it can only have the values 0 (false) and 1 (true). the result from (a < b) is a bool (in an int) not in a bit.
Aug 10 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgmfml$2fr1$1 digitaldaemon.com...
 
I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
there is the implication that there is none of this tri-state confusion
nonsense we find in C, but others obviously don't see it that way.


"bool" is
used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

It gives the impression that it has "bit" semantics! A bit is an integer in the range [0, 1]: bit a; a = 0.1; /* results in 0 */ a = 1.1; /* results in 1 */ a = 2; /* results in 0 */ a = 3; /* results in 1 */ A boolean, on the other hand, has no arithmetic, different casting semantics, no defined integral value in memory, and different purposes. It has an identical value range, but so do ubyte and char.
Aug 04 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgn2pr$bk$1 digitaldaemon.com...
 Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgmfml$2fr1$1 digitaldaemon.com...

I've put a bool alias for bit in 0.69. I found "bit" to be appealing,




there is the implication that there is none of this tri-state confusion
nonsense we find in C, but others obviously don't see it that way.


"bool" is
used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

It gives the impression that it has "bit" semantics! A bit is an integer in the range [0, 1]: bit a; a = 0.1; /* results in 0 */ a = 1.1; /* results in 1 */ a = 2; /* results in 0 */ a = 3; /* results in 1 */ A boolean, on the other hand, has no arithmetic, different casting semantics, no defined integral value in memory, and different purposes. It has an identical value range, but so do ubyte and char.

Just make: 1. bit implicitly convertible to 0 or 1. 2. casting from x to a bit be defined by: cast(bit)x => (x != 0) fulfilling both roles neatly. (Your third and fourth examples would set a to true.)
Aug 05 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 A boolean, on the other hand, has no arithmetic, different casting
 semantics, no defined integral value in memory, and different purposes.
   It has an identical value range, but so do ubyte and char.

Just make: 1. bit implicitly convertible to 0 or 1. 2. casting from x to a bit be defined by: cast(bit)x => (x != 0)

but what about the other way ? int i; cast(boolean)i (implies i!=0) cast(bit)i (implies i&1, given that cast(byte)i is i&0xFF) and here lies the reason for (and difference of) boolean and bit.
Aug 05 2003
parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bgoefc$1b9o$1 digitaldaemon.com...
 A boolean, on the other hand, has no arithmetic, different casting
 semantics, no defined integral value in memory, and different



   It has an identical value range, but so do ubyte and char.

1. bit implicitly convertible to 0 or 1. 2. casting from x to a bit be defined by: cast(bit)x => (x != 0)

int i; cast(boolean)i (implies i!=0) cast(bit)i (implies i&1, given that cast(byte)i is i&0xFF) and here lies the reason for (and difference of) boolean and bit.

Ok, I see what you are driving at. But the cast(bit)i being (i&1) is not necessary if the former is supported.
Aug 05 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgn2pr$bk$1 digitaldaemon.com...
 
Walter wrote:


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgmfml$2fr1$1 digitaldaemon.com...


I've put a bool alias for bit in 0.69. I found "bit" to be appealing,




as
there is the implication that there is none of this tri-state confusion
nonsense we find in C, but others obviously don't see it that way.


"bool" is
used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

It gives the impression that it has "bit" semantics! A bit is an integer in the range [0, 1]: bit a; a = 0.1; /* results in 0 */ a = 1.1; /* results in 1 */ a = 2; /* results in 0 */ a = 3; /* results in 1 */ A boolean, on the other hand, has no arithmetic, different casting semantics, no defined integral value in memory, and different purposes. It has an identical value range, but so do ubyte and char.

Just make: 1. bit implicitly convertible to 0 or 1. 2. casting from x to a bit be defined by: cast(bit)x => (x != 0)

Which is boolean semantics, not bit.
 fulfilling both roles neatly. (Your third and fourth examples would set a to
 true.)

That it can be forced to behave similar to a bit using a lot of casting and support code doesn't change the fact that it's NOT A BIT.
Aug 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bgpj3f$2gh8$1 digitaldaemon.com...
 That it can be forced to behave similar to a bit using a lot of casting
 and support code doesn't change the fact that it's NOT A BIT.

All it would be is: bit b = cast(bit)(d & 1);
Aug 07 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgpj3f$2gh8$1 digitaldaemon.com...
 
That it can be forced to behave similar to a bit using a lot of casting
and support code doesn't change the fact that it's NOT A BIT.

All it would be is: bit b = cast(bit)(d & 1);

That it can be forced to behave similar to a bit using a lot of casting and support code doesn't change the fact that it's NOT A BIT.
Aug 08 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bh0c75$2ppg$1 digitaldaemon.com...
 Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgpj3f$2gh8$1 digitaldaemon.com...

That it can be forced to behave similar to a bit using a lot of casting
and support code doesn't change the fact that it's NOT A BIT.

All it would be is: bit b = cast(bit)(d & 1);

That it can be forced to behave similar to a bit using a lot of casting and support code doesn't change the fact that it's NOT A BIT.

I'm with you, my bold bool brother
Aug 08 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bh0c75$2ppg$1 digitaldaemon.com...
 Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgpj3f$2gh8$1 digitaldaemon.com...
That it can be forced to behave similar to a bit using a lot of casting
and support code doesn't change the fact that it's NOT A BIT.

bit b = cast(bit)(d & 1);

and support code doesn't change the fact that it's NOT A BIT.

I disagree with the assessment that it's a lot of casting and support code. There's only one case, shown above, needing it. I don't think that justifies adding another basic type.
Aug 09 2003
prev sibling parent Mark T <Mark_member pathlink.com> writes:
after a quick google search found this interesting piece on C and Ada bit fields
representation:

http://www.ankh-morpork.com/Simon/adabook/c3_7.htm
Aug 05 2003
prev sibling next sibling parent reply Bill Cox <bill viasic.com> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgmfml$2fr1$1 digitaldaemon.com...
 
I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
there is the implication that there is none of this tri-state confusion
nonsense we find in C, but others obviously don't see it that way.


used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

Hi, Walter. By adding the alias for bool in a core library (is it in Phobos?), you've made me happy. I just didn't want to deal with resolving conflicting definition of 'bool', as I did in C and C++. Bill
Aug 06 2003
parent "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3F310C79.7080703 viasic.com...
 By adding the alias for bool in a core library (is it in Phobos?),
 you've made me happy.  I just didn't want to deal with resolving
 conflicting definition of 'bool', as I did in C and C++.

I think you might be the only one happy with that besides myself <g>.
Aug 07 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bgmnb5$2n2b$1 digitaldaemon.com...
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bgmfml$2fr1$1 digitaldaemon.com...
 I've put a bool alias for bit in 0.69. I found "bit" to be appealing,



 there is the implication that there is none of this tri-state



 nonsense we find in C, but others obviously don't see it that way.


 used in C and C++.

comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

Mostly they're used to typing 'bool' instead. ;) If it's not in the base language, there *will* end up being many incompatible and conflicting definitions of bool. Once this starts proliferating it will be impossible to add a standard bool type without breaking existing code, as all builtin types are keywords. Personally I don't mind using 0 and 1 instead of true and false; it's shorter to type. Pesky automatic conversions may bite you though. I guess people just want a distinct boolean type that's incompatible with int types, though explicit conversions should still be possible. Helps catch certain kinds of errors. I think the biggest reason may be that you can't use bit as an out parameter. Last I checked you couldn't have pointers to bit either, but I've heard rumors here that it is now possible. Sean
Aug 08 2003
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bgvm9a$25g6$1 digitaldaemon.com...
 I think the biggest reason may be that you can't use bit as an out
 parameter.  Last I checked you couldn't have pointers to bit either, but
 I've heard rumors here that it is now possible.

It's implemented in 0.69.
Aug 09 2003
prev sibling parent reply Frank Wills <fdwills sandarh.com> writes:
Burton Radons wrote:
 Matthew Wilson wrote:
 
 Wearing my heretical pragmatist hat, may I pose the question: why do 
 we have
 a bit type? I am at a loss to think why it is useful (or more useful than
 bit fields).

Its semantics are for boolean. It should be renamed - I want "boolean", as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

boolean. I'd have to retrain my fingers to type the extra "ean" letters. My eyes too, because I'm pretty used to seeing "bool", not boolean. However, here's my opinion. Walter is doing all the work of creating the language and developing the compiler. If he likes bit, I can type bit. If there is a real technical reason for a boolean type, I'd be happy to type bool (or boolean if I must.) Mostly I think we are splitting hairs (or bits?) here.
Aug 06 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
"Frank Wills" <fdwills sandarh.com> wrote in message
news:bgsm61$2cd9$1 digitaldaemon.com...
 Burton Radons wrote:
 Matthew Wilson wrote:

 Wearing my heretical pragmatist hat, may I pose the question: why do
 we have
 a bit type? I am at a loss to think why it is useful (or more useful



 bit fields).

Its semantics are for boolean. It should be renamed - I want "boolean", as "bool" is just lazy. Walter, is there any reason why it hasn't been renamed?

boolean. I'd have to retrain my fingers to type the extra "ean" letters. My eyes too, because I'm pretty used to seeing "bool", not boolean.

I don't care whether it's bool or boolean. Arguably, since we are using C's terse naming, i.e. int rather than integer, then we should go for bool. It'll also save fatuous editing when porting between C++ and D. But overall, don't care.
 However, here's my opinion. Walter is doing all the
 work of creating the language and developing the
 compiler. If he likes bit, I can type bit. If there
 is a real technical reason for a boolean type, I'd
 be happy to type bool (or boolean if I must.) Mostly
 I think we are splitting hairs (or bits?) here.

Not so. The differences are very important, for the reasons already mentioned several times. We *must* have bool/boolean type, it *must* not be bit-size, and it *should* be the same size as int.
Aug 06 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must* not

 bit-size, and it *should* be the same size as int.

I disagree with the latter part of that. we *must* have a boolean-type with boolean semantics it *can* be implemented in *any* way bit, byte, int, long as long as its passable in,out,inout and you can have a pointer to it. if declared as a extern( C ) boolean b; then it *must* be implemented as an int (same for boolean params in extern(C or Windows) functions. int i; cast(boolean)i equiv to i!=0 if there is a 'bit' type is should be have 'bit' semantics, which means it _can_ be "in" only as bit pointers are extra work. cast(bit)i equiv to i&1 (in line with byte and short cast operators).
Aug 07 2003
parent Mark T <Mark_member pathlink.com> writes:
In article <bgtu7o$hu1$1 digitaldaemon.com>, Mike Wynn says...
 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must* not

 bit-size, and it *should* be the same size as int.

I disagree with the latter part of that. we *must* have a boolean-type with boolean semantics it *can* be implemented in *any* way bit, byte, int, long as long as its passable in,out,inout and you can have a pointer to it. if declared as a extern( C ) boolean b; then it *must* be implemented as an int (same for boolean params in extern(C or Windows) functions. int i; cast(boolean)i equiv to i!=0 if there is a 'bit' type is should be have 'bit' semantics, which means it _can_ be "in" only as bit pointers are extra work. cast(bit)i equiv to i&1 (in line with byte and short cast operators).

I agree with this and many others do also (why does Walter fight this??) It may be Walter's language now but hopefully in the future it will be more than that, I don't think of Stroustrap as "owning" C++
Aug 08 2003
prev sibling parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bgsml6$2cu1$1 digitaldaemon.com...
 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must* not be
 bit-size, and it *should* be the same size as int.

If bits are not going to be usable as out parameters, then we definitely need separate bool (which can be used as out parameter), otherwise I can live with bool as language defined typedef for bit. Bit size should be really one bit and bit arrays should be "packed" (ie an array with 8 items should be only 1 byte long); I think this is true now. Bool size does *not* need to be the same as int at all, when it is not defined as extern(C). C++ uses one byte for bools and it is definitely different from int.
Aug 10 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Peter Hercek" <vvp no.post.spam.sk> wrote in message
news:bh6o62$2kru$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message

 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must* not


 bit-size, and it *should* be the same size as int.

If bits are not going to be usable as out parameters, then we definitely

  separate bool (which can be used as out parameter), otherwise I can live

  bool as language defined typedef for bit. Bit size should be really one

  and bit arrays should be "packed" (ie an array with 8 items should be

  1 byte long); I think this is true now.
 Bool size does *not* need to be the same as int at all, when it is not

  as extern(C). C++ uses one byte for bools and it is definitely different

exactly C++ uses ...... C however uses "int" (and that's a C "int" NOT a D int) and D only has C linkage not C++
Aug 10 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bh6oqf$2lbm$1 digitaldaemon.com...
 "Peter Hercek" <vvp no.post.spam.sk> wrote in message
 news:bh6o62$2kru$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message

 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must*



 be
 bit-size, and it *should* be the same size as int.

If bits are not going to be usable as out parameters, then we definitely

  separate bool (which can be used as out parameter), otherwise I can


 with
  bool as language defined typedef for bit. Bit size should be really one

  and bit arrays should be "packed" (ie an array with 8 items should be

  1 byte long); I think this is true now.
 Bool size does *not* need to be the same as int at all, when it is not

  as extern(C). C++ uses one byte for bools and it is definitely


 from int.

 exactly C++ uses ...... C however uses "int" (and that's a C "int" NOT a D
 int)
 and D only has C linkage not C++

Well, both C++ (bool) and C (_Bool) have native bool types, and they are implemented as 8-bit quantities on every compiler I have access to. But most pre-C99 boolean types in C are implemented (correctly) as int, and so should D's.
Aug 10 2003
next sibling parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh6va4$2rfm$1 digitaldaemon.com...

 Well, both C++ (bool) and C (_Bool) have native bool types, and they are
 implemented as 8-bit quantities on every compiler I have access to.

 But most pre-C99 boolean types in C are implemented (correctly) as int, and
 so should D's.

nose into this too much, I'm only interested why int is better. In memory individual variables would be aligned anyway and in arrays and sometimes structs it is good to consume less memory IMHO. From programmer's point of view the sematics is different from int.
Aug 10 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Peter Hercek" <vvp no.post.spam.sk> wrote in message
news:bh74g5$313v$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message


 Well, both C++ (bool) and C (_Bool) have native bool types, and they are
 implemented as 8-bit quantities on every compiler I have access to.

 But most pre-C99 boolean types in C are implemented (correctly) as int,


 so should D's.


  nose into this too much, I'm only interested why int is better. In memory

  variables would be aligned anyway and in arrays and sometimes structs it

  to consume less memory IMHO. From programmer's point of view the sematics

  different from int.

68K can read byte at byte alignment, short and int at 16 bit alignment ARM can read byte byte, short 16bit aligned, int only at 32bit aligned. x86 any at any but there are performance issues with unalign loading and many compiler align the stack on cache line boundaries for speed. int is not better, it is just what the pre-C99 spec uses (same as originally C would not allow structs to be passed by value) as far as I'm aware void func( bool a, bool b, bool c ){ .... } will use 3 stack slots (or registers) [not checked] so will push 3 16 bit quantites under dos, push 3 dwords under win32/unix and will use r0..r2 on Arm. thus "int" [C def] rather than packing them into bytes or bits.

Aug 11 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
1. Efficiency ... mostly. However, I recognise that int is not the most
efficient in all circumstances, just a significant proportion of them.
2. Safety. Since we are interoperating with Win32, where it is possible for
BOOL to return a "true" value outside of 1-255, which would be missed. If D
does what C++ does, which is to do an implict test, as in

  int        i;
  bool    b = i;

 is translated to

  int        i
  bool    b = (i != 0) ? true : false;

then it is safe, but we're back to inefficiency. Incidentally, only
CodeWarrior and Visual C++ warn about the efficiency concerns of this
conversion. All other Win32 compilers (that I have access to, which is
Borland, Digital Mars, GCC, Intel, Watcom) do not warn.

I'm very interested in efficiency, but am more interested in safety. My
perhaps simplistic notion, therefore, is to make bool(ean) be the same size
as int. If someone can come up with an efficient & safe scheme that is
better, I'll jump on board

"Peter Hercek" <vvp no.post.spam.sk> wrote in message
news:bh74g5$313v$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message


 Well, both C++ (bool) and C (_Bool) have native bool types, and they are
 implemented as 8-bit quantities on every compiler I have access to.

 But most pre-C99 boolean types in C are implemented (correctly) as int,


 so should D's.


  nose into this too much, I'm only interested why int is better. In memory

  variables would be aligned anyway and in arrays and sometimes structs it

  to consume less memory IMHO. From programmer's point of view the sematics

  different from int.

Aug 11 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
What we'd all like to have is a choice between a fast bool and a small bool.

We need a "pragma packed" decorator.  ;)

Or the compiler could be smart about it and use 1-byte bools for small
fixed-size arrays, 4-byte bools for single bools that aren't next to any
other bools in memory, and 1-bit bools for large arrays.  I wonder if the
sizeof(bit) could be changed depending on the situation without making the
language really difficult.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh6va4$2rfm$1 digitaldaemon.com...
 Well, both C++ (bool) and C (_Bool) have native bool types, and they are
 implemented as 8-bit quantities on every compiler I have access to.

 But most pre-C99 boolean types in C are implemented (correctly) as int,

 so should D's.

Aug 11 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Now you're talking! ;)

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bh8ia5$1gpn$1 digitaldaemon.com...
 What we'd all like to have is a choice between a fast bool and a small

 We need a "pragma packed" decorator.  ;)

 Or the compiler could be smart about it and use 1-byte bools for small
 fixed-size arrays, 4-byte bools for single bools that aren't next to any
 other bools in memory, and 1-bit bools for large arrays.  I wonder if the
 sizeof(bit) could be changed depending on the situation without making the
 language really difficult.

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh6va4$2rfm$1 digitaldaemon.com...
 Well, both C++ (bool) and C (_Bool) have native bool types, and they are
 implemented as 8-bit quantities on every compiler I have access to.

 But most pre-C99 boolean types in C are implemented (correctly) as int,

 so should D's.


Aug 11 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Well if the compiler can do bit*, it should be able to do out bit.  There is
no technical reason why this wouldn't work, it's just a matter of Walter's
time and inclination.

Sean

"Peter Hercek" <vvp no.post.spam.sk> wrote in message
news:bh6o62$2kru$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message

 Not so. The differences are very important, for the reasons already
 mentioned several times. We *must* have bool/boolean type, it *must* not


 bit-size, and it *should* be the same size as int.

If bits are not going to be usable as out parameters, then we definitely

  separate bool (which can be used as out parameter), otherwise I can live

  bool as language defined typedef for bit. Bit size should be really one

  and bit arrays should be "packed" (ie an array with 8 items should be

  1 byte long); I think this is true now.
 Bool size does *not* need to be the same as int at all, when it is not

  as extern(C). C++ uses one byte for bools and it is definitely different

Aug 11 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Frank Wills" <fdwills sandarh.com> wrote in message
news:bgk5n1$bs2$1 digitaldaemon.com...
 Mike,

 Sure, sure, yes, yes, I imagine that most
 people on this list understand everything you
 are explaining, and the issues involved
 (who on this list doesn't know what a bit is,
 and that it is a part of a larger addressable
 unit in memory?)

I appologise, just giving what I could remember from the answer I got from Walter when I tried `out bit b` ages ago. I assumed no out bit meant no bit * too, so never bothered with bit * as a solution (or inout bit) I think I know what you mean, but "part of a larger addressable unit in memory" bits is smallest sub part of the addressable units of the CPU, isnt it more that all CPU's (that I've used) only allow direct addressing to multi bit quantities units I assumed everyone know that, as they all knew most RISC cpus can only address units at unit alignment. I'm in the drop bit and give us a boolean conceptual type camp. or if you can have bit *, bit[] give us full useage of it, allow an int to be cast to a bit[] and vice-versa or even a int[] to a bit[] and allow set scanning etc in the bit[]. as I've said before I believe a language should be driven by its semantics and not its implementation the better you can tell a compiler what you want done (rather than how) the better the chances the compiler can optimise your code. my desire for boolean is that the storage of a boolean in undefined, so extern C api's which use int for boolean and D code with booleans can interoperate without the need to cast.
Aug 04 2003