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

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

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

>
>

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.

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.

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

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