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.
 
 


Walter, any chance you will answer my question, or
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.


 Yes, that is a good idea.


 Walter, any chance you will answer my question, or
 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




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


expression

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


bool

 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




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






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


the C bool as an alias to int is poor (again its implementation over
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.




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




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


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.


'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


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.


'bit' does that.


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


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


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.


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


 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.


 '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


 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.


 'bit' does that.


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


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


 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.


 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


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


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


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


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




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.


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


FPGA

 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.


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.


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


conventions

 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


 conventions

 unless there are good reasons to stray.


 Yes, exactly.


well then bit ain't bool and bool aint bit !!
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,








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)

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






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.


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.


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




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


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,






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.


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?
 


I guess I'm lazy, because I like bool better than
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






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 guess I'm lazy, because I like bool better than
 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


be

 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


be

 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


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.

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


 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.

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


[snip]

 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.


Why it should be int and not 8bit quantity? Sorry, I do not want to poke my
 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


news:bh6va4$2rfm$1 digitaldaemon.com...


 [snip]

 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.


 Why it should be int and not 8bit quantity? Sorry, I do not want to poke


my

  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.


not on all archs, (read byte as 8bit, short->16bit, int->32bit [D defs])
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


news:bh6va4$2rfm$1 digitaldaemon.com...


 [snip]

 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.


 Why it should be int and not 8bit quantity? Sorry, I do not want to poke


my

  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 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,


and

 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


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,


 and

 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


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