"Sean L. Palmer" <spalmer@iname.com> wrote in message news:abt77j$2fh9$1@digitaldaemon.com...

> Did anyone think having pointers to bits be extra-special pointers with a combined bit index was a good idea?  If not, why not?

Yes, exactly. As long as we can have bit*, I don't care about all the bool stuff. Especially since "bool" is one character longer than "bit". =)

"Martin M. Pedersen" wrote:

> Alternatively, references and pointers to bits could be implemented. They would be special, though. It would require a special pointer representation using an offset into a byte, or possibly a bit-mask instead. Offsets would be the best choice, I think, as they would support bit-slices better. Bit-masks would probably perform better in some situations. A downside of a special pointer representation is that it cannot be casted to anything else, so type safety needs to be enforced, and no casts should be allowed.

Yes, pointers-to-bool should be implemented.  After all, we have pointers-to-functions, delegates, etc.  We cannot assume that all pointers are just simple address values.

> If performance is the primary concern (and I think it is), a byte-sized "bool" should be introduced. I don't think it should be stored in a bit, but the compiler could convert between "bool"s and "bit"s without problems. This would make "bit" the choice for arrays (bitmaps), and "bool" for almost any other purpose.

If you want a byte-sized variable, use 'byte' or 'ubyte'.



Really, I think that 'bool' should be a logical type, not a mathematical one. We can have two 1-bit types:

* bool: returned by comparisons, required by for/while/if tests, NOT a
mathematical type
* bit: a mathematical type

Both can be bit-packed into arrays, and you should be able to have pointers to them.  Internally, bool's and bit's are identical, but we separate them in syntax so that we can have more explicit typechecking.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CE26570.1912AF41@deming-os.org...

> * bool: returned by comparisons, required by for/while/if tests, NOT a
> mathematical type
> * bit: a mathematical type
>
> Both can be bit-packed into arrays, and you should be able to have
pointers to
> them.  Internally, bool's and bit's are identical, but we separate them in syntax so that we can have more explicit typechecking.

Much like char and byte are the same, but are considered different by the compiler... I'm pretty happy without it, but I wouldn't mind to have it, as well. =)

On Wed, 15 May 2002 14:42:29 +0400, "Pavel Minayev" <evilone@omen.ru> wrote:

>"Sean L. Palmer" <spalmer@iname.com> wrote in message news:abt77j$2fh9$1@digitaldaemon.com...
>
>> Did anyone think having pointers to bits be extra-special pointers with a combined bit index was a good idea?  If not, why not?
>
>Yes, exactly. As long as we can have bit*, I don't care about all the bool stuff. Especially since "bool" is one character longer than "bit". =)

Err, can someone produce a valid example of where you need a bit pointer or reference that cannot be refactored to avoid it?

I have hit this problem with bit three times already while writing D code.  Each time I changed the code and the problem disappeared... after awhile, I won't write such code any more.

Oh, and has anyone found an example of where Quake 3's lack of security in the DLLs has been exploited?  One example is all I've asked for.  I mean, I was expecting at least one wanker to have put up a malicious bot, then I could point out how quickly the problem was found and he was ostracized.  It's a waste of a good counterpoint.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:abtdm0$2kqq$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:abt871$2ggc$1@digitaldaemon.com...
>
> > Surely in D, true and false are available at very least in some standard library.  If it is, I can't find it anywhere on the D website.  If not,
I
>
> true and false are language keywords. They cannot be redefined.
>
> > What happens in D when you do something like this:
> >
> > enum bool { false=0, true=1 };
> > enum bool { false=0, true=1 };
> > enum bool { false=0, true=1 };
> >
> > ?  Is it an error?  Is it ok, since they all match?
>
> I guess no. It'll give a redeclaration error.
>
> By the way, it seems to be an interesting idea, to define bool as:
>
>     enum bool: bit
>     {
>         false = 0,
>         true = 1
>     }
>
> Put it somewhere in the library (maybe in some unit that's imported
> automaticallly), and remove the true and false keywords from
> the language... then, you will be able to cast bool to bit (and thus,
> to any integer) implicitly, but an integer would require an explicit
> cast to be converted to bool...
>



No, please don't remove the keywords true and false from
the language! They are keywords in C++, Pascal and Java
and for very good reasons! A boolean is a very important
type in programming. Saying it can be easily emulated using
bit's, bytes, words etcetera etcetera is not helping.
We need a bool! Why? Because in C, this is perfectly valid:


typedef unsigned char bool;
#define false 0
#define true 1

// ...

bool bMyBool = 2;
if (bMyBool == false)
    printf ("It is false\n");

else if (bMyBool == true)
    printf ("It is true\n");

else
    printf ("Mmmm...It is neither true or false!!\n");


Conversely, this is also legal:


bool bBool1 = true;
bool bBool2 = 2;

// ...

if (bBool1 == bBool2)
    SaveWorld();
else
    StartNuclearWar();



This sucks!
Please don't make the same mistakes with D.

A bool can only be true or false.
Defining it as an enum of type bit will
ofcourse make sure that there are no problems
like this, but then the problem that we cannot
use it as an out parameter remains. I do not
want to have to do casting just to assign a
byte sized 'bool' to a bit sized 'bool'!

I like the idea of storing them in bits,
but being able to use them as out parameters,
typesafe and without the need for casting,
is much more important to me! In the end I
don't really care that bools take up one byte
instead of one bit, as long as they are typesafe
and well defined. C++, Java and Pascal bool's
were all fine to me.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CE26570.1912AF41@deming-os.org...
> "Martin M. Pedersen" wrote:
>
> > Alternatively, references and pointers to bits could be implemented.
They
> > would be special, though. It would require a special pointer
representation
> > using an offset into a byte, or possibly a bit-mask instead. Offsets
would
> > be the best choice, I think, as they would support bit-slices better. Bit-masks would probably perform better in some situations. A downside
of a
> > special pointer representation is that it cannot be casted to anything
else,
> > so type safety needs to be enforced, and no casts should be allowed.
>
> Yes, pointers-to-bool should be implemented.  After all, we have pointers-to-functions, delegates, etc.  We cannot assume that all pointers
are
> just simple address values.
>
> > If performance is the primary concern (and I think it is), a byte-sized "bool" should be introduced. I don't think it should be stored in a bit,
but
> > the compiler could convert between "bool"s and "bit"s without problems.
This
> > would make "bit" the choice for arrays (bitmaps), and "bool" for almost
any
> > other purpose.
>
> If you want a byte-sized variable, use 'byte' or 'ubyte'.
>
>
>
> Really, I think that 'bool' should be a logical type, not a mathematical
one.
> We can have two 1-bit types:
>
> * bool: returned by comparisons, required by for/while/if tests, NOT a
> mathematical type
> * bit: a mathematical type
>
> Both can be bit-packed into arrays, and you should be able to have
pointers to
> them.  Internally, bool's and bit's are identical, but we separate them in syntax so that we can have more explicit typechecking.
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>



Using ubyte or byte as booleans is not typesafe. The problem with using bit as a boolean is that you cannot do this:


void performSomeTests (out bit a, b, c)
{
    a = foo();
    b = bar();
    c = baz();
}

bit a, b, c;
performSomeTests (a, b, c);


Because this would require pointer to bits, which
are not implemented. You could solve this problem
in two ways:

1)  Implement pointers to bits.
2)  Create a byte sized boolean type.

Both ensure type safety, so a bool / bit cannot
become 2, 3, etc, but only 0 (false) or 1 (true).
However if bool is bit sized this will cause
problems interfacing to other languages, the
most of which will use byte-sized booleans.

I would like it the most to keep bit the way
it is and define three new types, bool, bool16
and bool32, of 8, 16 and 32 bits respectively.
Use bool as the primary boolean type, make them
all typesafe so they can only assume the values
false and true and then make them implicitly
convertible to one and another, as well as to
bit. bool16 and bool32 can be used to interface
with C code in a typesafe manner, while bit
can be used in places where size really matters,
such as very large arrays of boolean values.

If this is to much to ask I would settle for
a simple byte sized bool C++ style, and live
with the casting needed to convert 16 or 32 bit
booleans from C code to bool.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:a0p4euovk8lcshb5kk5r7t5l7qdmjnv380@4ax.com...
> On Wed, 15 May 2002 14:42:29 +0400, "Pavel Minayev" <evilone@omen.ru> wrote:
>
> >"Sean L. Palmer" <spalmer@iname.com> wrote in message news:abt77j$2fh9$1@digitaldaemon.com...
> >
> >> Did anyone think having pointers to bits be extra-special pointers with
a
> >> combined bit index was a good idea?  If not, why not?
> >
> >Yes, exactly. As long as we can have bit*, I don't care about all the bool stuff. Especially since "bool" is one character longer than "bit". =)

bit* seems like a good idea too, but I don't know how difficult it is to implement. I could live without bit pointers, but not without good bool support...


>
> Err, can someone produce a valid example of where you need a bit pointer or reference that cannot be refactored to avoid it?
>

void performSomeTests (out bit a, b, c)
{
    a = foo();
    b = bar();
    c = baz();
}

bit a, b, c;
performSomeTests (a, b, c);


It seems to me that being able to return multiple booleans from a function is something done quitte often.

This example is lame ofcourse, but if the function wouldn't return void but some number or whatever I think the problem would be more clear.

Come to think of it, when programming COM you normally always return a HRESULT, so you can forget about returning bits at all!

I like the idea of boolean values being stored in bits a lot, but this is just to high a price to pay!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abu41b$6g3$1@digitaldaemon.com...

> No, please don't remove the keywords true and false from
> the language! They are keywords in C++, Pascal and Java
> and for very good reasons! A boolean is a very important
> type in programming. Saying it can be easily emulated using
> bit's, bytes, words etcetera etcetera is not helping.
> We need a bool! Why? Because in C, this is perfectly valid:
...

This ain't the case. By inheriting enum from the bit type, the ONLY two legal values will be true and false.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:abu7v0$9t1$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abu41b$6g3$1@digitaldaemon.com...
>
> > No, please don't remove the keywords true and false from
> > the language! They are keywords in C++, Pascal and Java
> > and for very good reasons! A boolean is a very important
> > type in programming. Saying it can be easily emulated using
> > bit's, bytes, words etcetera etcetera is not helping.
> > We need a bool! Why? Because in C, this is perfectly valid:
> ...
>
> This ain't the case. By inheriting enum from the bit type, the ONLY two legal values will be true and false.
>
>


You are right, but then we still keep the problem
of not being able to use them as out parameters.
Walter, what do true and false do at the moment?
I thought they where already defined as being 0
and 1...

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:abubnh$d8t$1@digitaldaemon.com...
> You are right, but then we still keep the problem
> of not being able to use them as out parameters.
> Walter, what do true and false do at the moment?
> I thought they where already defined as being 0
> and 1...

They're 0 and 1 of type bit.

As this thread shows, unfortunately, there simply is no right way to implement a boolean type. I remember the same discussion raging with C, with no consenus resolution.