Like you say, its a matter if opionon,

> uint flags = (Carry << 6) | Overflow;

is far easier for me to read then

>      flags = 0;
>      if (Carry )
>          flags |= 1<<6;
>      if (Overflow)
>          flags |= 1;

>  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);

Look at all that repetition! ;).

Charles

In article <c9m71a$149k$1@digitaldaemon.com>, Derek Parnell says...
>
>On Wed, 2 Jun 2004 20:00:26 -0700, Walter wrote:
>
>> "Derek Parnell" <derek@psych.ward> wrote in message news:c9m1v3$sv4$1@digitaldaemon.com...
>>>> - but regarding
>>>> the principle that a bool is not arithmetic, if you have been following
>> this
>>>> forum, you'll know you are in a very small minority here.
>>>
>>> void main( )
>>> {
>>>     char[] myHat = "red";
>>>     char[] myCoat = "blue";
>>>     bool a = (myHat == "red");
>>>     bool b = (myCoat == "blue");
>>>     int  c;
>>>
>>>     c = (3*a) + (b*b);
>>>
>>>     printf("%d %d %d\n",a,b,c);
>>> }
>>>
>>>
>>> LOL!!!! Why this code above should compile is beyond my understanding. In
>>> English it is like saying "Q:What is the sum of three times (is my hat
>>> red?) and the square of (is my coat blue?)?  A: 4!"
>> 
>> Here are some uses that I use now and then:
>> --------------------------------
>> 1) Assembling a 'flags variable' from boolean components:
>> 
>>     bool Carry;
>>     bool Overflow;
>>     uint flags = (Carry << 6) | Overflow;
>
>And I would have coded it more explicitly...
>
>      uint flags = (Carry ? 1<<6 : 0) | (Overflow? 1 : 0);
>
>or maybe even ...
>
>      flags = 0;
>      if (Carry )
>          flags |= 1<<6;
>      if (Overflow)
>          flags |= 1;
>
>
>> 2) Add booleans to state variable to, for example, conditionally advance to the next state in a state machine:
>> 
>>     state += (foo == bar);
>
>Not explict enough for my 'self-documenting code' standards.
>
>      if (foo == bar)
>          state += 1;
> 
>> 3) Use bools as an index into an array:
>> 
>> char[] response[2];
>> printf("answer is %.*s\n", response[ foo == bar ]);
>
>  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);
>
>or
>
>  char[] response[2];
>  char[] msg;
>
>  // Because one day there might be more than two potential messages.
>  switch (foo)
>  {
>    case foo:
>        msg = response[0];
>        break;
>    default:
>        msg = response[1];
>  };
>  printf("answer is %.*s\n", msg);
>
> 
>> ------------------------------------
>> Of course, these can all be uglified with cast(int)b, or with (b?1:0),
>
>"uglified"? One person's "ugly" is another person "documentation" ;-)
>
>> but I just don't see the paradigm problem with bool being a 1 or a 0 integer.
>
>True, its just a way of thinking. A metaphor, if you will.
>
>I prefer writing code that other people can easily read, so that they can understand my intentions. Brevity, for its own sake, does not guarentee legibilty.
>
>I would always prefer clearest code over fastest code.
>
>-- 
>Derek
>3/Jun/04 1:27:35 PM

Well said, I've always used bit ( although I missed where using int gives a gain in performance , Ill have to try to hunt it down.

C
In article <c9m7qp$15la$1@digitaldaemon.com>, James McComb says...
>
>Arcane Jill wrote:
>
>> I've just noticed that the keyword "bool" is accepted by the compiler. Turns out this is because it's defined in "object.d" as an alias for bit.
>
>My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int.
>
>Walter can continue this battle by officially defining boolean as an alias for bit as well, and then Matthew will be forced to give his alias for int an awkward name like matthewsbool, or maybe truefalse.
>
>Like many people who post to this group, I like the idea of a strongly-typed boolean type. But the language doesn't define one. So I move on. Instead of using bool, I use bit. Bool is just an alias for bit anyway, so why bother with bool? Just use bit, and move on. But what if I absolutely *must* have an int-based bool for performance reasons? Just use int, and move on.
>
>What about Matthew's boolean type? I think that this type just creates confusion and inconsistency. Is D going to have *three* boolean types now, bit, bool and boolean? Let's cut this proliferation of boolean types off at the beginning. Just use bit (or if necessary, int).
>
>But what about the strongly-typed boolean we want? By all means, keep requesting it. But the language does not define one (yet), so until and unless it does, please don't add to the confusion by trying to define your own.
>
>James McComb
>

In article <c9na1h$2nf1$1@digitaldaemon.com>, Lord Syl says...

>Boolean expressions as part of the library? That's counterproductive:
>As a example, one of the advantages of D is that strings are directly built into
>the core.
>Then, if we do the opposite with something as basic as boolean expressions, we
>are improving here then screw there. Bad idea.


So don't use my class. I'm not forcing you.

But please don't tell me not to write the code that I want to use. If it want it, and it does not exist, I will write it, and I will use it. If I could figure out a way to write a class that made toast and smothered it in strawberry jam, I'd write that too. I don't CARE if other people don't use it. They're not who I'm writing it for. I wrote it for me.

Aha - you say - then why put it in a library? Answer - it is required BY MY CODE (which is itself in a library).

So really, all I actually did, about which you can complain, is tell people about it.

Jill

In article <c9n5ik$2h0d$1@digitaldaemon.com>, Matthew says...
>
>STLSoft has a library-based version of the null pointer, which works perfectly well in all circumstances. It's explained in "Imperfect C++", and one of the publisher's reviewers, who's on the C++ standards committee, asked if he could present the material to the standards committee. I've not heard anything since that time, and suspect it'll be rejected anyway, as it has one sneaky albeit, IMO, utterly reasonable, trick.

There's been some talk about this in the last two issues of CUJ.  Basically, they decided to add they keyword nullptr to the language to allow for meaningful error messages.  Usage will likely be pretty much the same as the recent library versions.

Sean

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
news:c9ln6r$du0$1@digitaldaemon.com...
...
> Well, I know you're skin's even thicker than mine, but you clearly _seem_
at a
> point of some exasperation to state that "and it's going to stay that way. There's a lot of very cool stuff coming for D, and I can't wait to get it implemented. I've had as much as I can take on the whole 15 years of bool business".
...

Can i be curious and ask what "cool stuff"? I am really interested :)

In article <c9nj0i$3ph$1@digitaldaemon.com>, Charlie says...
>
>Like you say, its a matter if opionon,
>
>> uint flags = (Carry << 6) | Overflow;
>
>is far easier for me to read then
>
>>      flags = 0;
>>      if (Carry )
>>          flags |= 1<<6;
>>      if (Overflow)
>>          flags |= 1;
>
>>  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);
>
>Look at all that repetition! ;).

uint flags = (Carry?1<<6:0) | (Overflow?1:0);

Looks pretty clear to me, if perhaps a bit more verbose than Walter's version :)

Sean

In article <c9nf7e$2vdb$1@digitaldaemon.com>, Bruno A. Costa says...
>
>Arcane Jill wrote:
>
>> I've just noticed that the keyword "bool" is accepted by the compiler. Turns out this is because it's defined in "object.d" as an alias for bit.
>> 
>> At the very least, this enables us to document our code, by having appropriate functions return bool instead of bit.
>> 
>> Walter, pending the implementation of a real non-arithmetic bool type, is
>> there any chance you could change this alias from bit to int? Then at
>> least opEquals() could return a bool. (Or better still, have opEquals()
>> return bool).
>> 
>
>Sorry, but i am not sure if it is a good idea. A bool being aliased to int would permit things like:
>
>bool b = 1000;
>
>which sounds strange, IMHO.
>
>Bruno.
>
>
>> Arcane Jill
>
Arcane: I agree with your thoughts, a bool should never be anything but true or false...which in this case is 1 or 0, so the whole !=0 or ==0 thing still works.


Everyone: I don't claim to be a "Rocket Scientist" type, but there are a few here whom in my mind, fall into that category, Walter being one (D's truly a "Marvel" to use and write code in)...also Arcane and Matthew come to mind as well. Plus there are many others here in the forum, who've given great ideas and feedback to improve "D", its just takes me a while to remember everyone's name and such. :))

Anywayz, the way I see it, Walter has given us a bool keyword which yes has been alias from a bit, to use within our own code that'll help self-doc when we're using the values as a "flag value." Also we have the two consts "true" and "false" defined in which to test against these boolean flag type values. So, how can it get any simplier? I really fail to see why there are so many threads on this subject, or why the sizeof(bool) really matters.

Guess my feet are still planted on the ground, and everyone else is there somewhere flying around me. So, maybe in time I'll understand why this bool thing is such a big deal. :(

on GDC  (linux)
Bool.test(digit.length==2)
actually does not pass in a value of 1 or 0 to your bool test function
then your bool throws a problem.

it seems like your bool implementation is not linux compatible :-(
if I take out that throw it now dies on an infinite loop
perhaps opCast has not yet been made on linux :-/

which means that I'm going to have to fork your BigInteger to use the old bit version....can you send me the diffs you did to make the print work ... *sigh*
I really liked the old version of this better without all these Big Bools.
sure bit isn't perfect...but having to write Bool.test
can't wait until subversion--then integration wouldn't be such a problem.
--Daniel
Sean Kelly wrote:

> In article <c9n5ik$2h0d$1@digitaldaemon.com>, Matthew says...
> 
>>STLSoft has a library-based version of the null pointer, which works perfectly
>>well in all circumstances. It's explained in "Imperfect C++", and one of the
>>publisher's reviewers, who's on the C++ standards committee, asked if he could
>>present the material to the standards committee. I've not heard anything since
>>that time, and suspect it'll be rejected anyway, as it has one sneaky albeit,
>>IMO, utterly reasonable, trick.
> 
> 
> There's been some talk about this in the last two issues of CUJ.  Basically,
> they decided to add they keyword nullptr to the language to allow for meaningful
> error messages.  Usage will likely be pretty much the same as the recent library
> versions.
> 
> Sean
> 
> 

"Sean Kelly" <sean@f4.ca> wrote in message news:c9nn2d$a1l$1@digitaldaemon.com...
> In article <c9n5ik$2h0d$1@digitaldaemon.com>, Matthew says...
> >
> >STLSoft has a library-based version of the null pointer, which works perfectly well in all circumstances. It's explained in "Imperfect C++", and one of the publisher's reviewers, who's on the C++ standards committee, asked if he could present the material to the standards committee. I've not heard anything since that time, and suspect it'll be rejected anyway, as it has one sneaky albeit, IMO, utterly reasonable, trick.
>
> There's been some talk about this in the last two issues of CUJ.  Basically, they decided to add they keyword nullptr to the language to allow for
meaningful
> error messages.  Usage will likely be pretty much the same as the recent
library
> versions.

But the problem with the new keyword is that it won't be available on old/current compilers, whereas my soln works for pretty much any compiler you can shake a stick at.

Anyway, I'm going to shut up about this one, since it'll be far too obviously advertisingly self-aggrandising. ;)

I had a brainwave about an hour ago and ditched the Bool class entirely. Instead, I did this:

typedef void* Bool;
const Bool FALSE = cast(Bool) 0;
const Bool TRUE = cast(Bool) 1;

Ah - the simple ideas are always the best!

And guess what? - Bool now gives me everything I want in terms of compile-time safety, but, in addition, is about as efficient as it gets. I re-did the tests I did earlier, and isolated them from each other (because I discovered that the compiler was doing some optimization even in a debug build in which I hadn't asked it to). These results are pretty cool:

----------------------------------------
bit b1 = 1;
0040AF74  mov         byte ptr [b1],1
----------------------------------------
byte b2 = 1;
0040AF80  mov         byte ptr [b2],1
----------------------------------------
int b3 = 1;
0040AF8C  mov         dword ptr [b3],1
----------------------------------------
void* b4 = cast(void*)1;
0040AF9C  mov         dword ptr [b4],1
----------------------------------------
Bool b5 = TRUE;
0040AFAC  mov         dword ptr [b5],1
----------------------------------------

So all those changes are now online, and I'm leaving it at that. If anyone is concerned that, for example, my function  isPrime() returns a Bool and not some other type, remember that you're most likely going to use these things in statements like:

>       if (isPrime(n))
>       {
>           /* do stuff */
>       }

which will compile perfectly anyway.

Regarding the Linux incompatibilty problem, I'm surprised that the expression (digit.length==2) yields a value other than 0 or 1. That has to be a bug. The workaround is of course to replace

>       toBool(digit.length==2):

(which throws an exception), with

>       cast(Bool)(digit.length==2);

which doesn't. Hopefully now no-one can object. A straightforward typedef to void* is at least as reasonable as an alias to int, and has the benefit of type-safety.

Arcane Jill