yay! now it will work in linux on gdc

Arcane Jill wrote:

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

In article <c9o5qf$100l$1@digitaldaemon.com>, Matthew says...
>
>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.

Yup.  I've seen the library examples and they work just fine.  I'll probably begin converting my code now to use one of those so I don't have to deal with it later :)

Sean

Sorry Jill;

I fail to see how your personal version of Bool is particularly typesafe. For example:

void main()
{
        typedef void* Bool;

        const Bool FALSE = cast(Bool) 0;
        const Bool TRUE = cast(Bool) 1;

        void foo (void *ack)
        {
        }

        Bool b = TRUE;
        foo (b);
}

I just passed a value of 1 as a void pointer argument, without a peep from the compiler. Is that what you had in mind? Walter's implementation of bit/bool, catches this test with flying colours ...

Without wishing to be pedantic, you might perhaps find some further reason to avoid fracturing this issue further within this post: c9nqcd$f21$1@digitaldaemon.com

Respectfully;

- Kris






"Daniel Horn" <hellcatv@hotmail.com> wrote in message news:c9o87e$13t3$1@digitaldaemon.com...
> yay! now it will work in linux on gdc
>
> Arcane Jill wrote:
>
> > 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
> >
> >

May I interject with an opinion from an outsider?.  You all live and breath programming, I suppose with a fairly limited number of languages.  As a scientist, I use programming seriously as a tool that must be as reliable as possible.  I only program part time, and I often have to read, decipher, and write code in multiple languages.  Generally, they are so diverse and so full of quirks and cute tricks that this is sometimes quite challenging, to say the least.

If you really want to expand the usefulness of D, you need to exert constant effort keep it simple and don't get fancy.  What I see in the boolean debate is anything but simple.  Let me reiterate a couple of principles (or opinions, if you like) that you have heard many times, and then add some comment on some obvious(?) pitfalls.

*****************************************************************************
1. A boolean type should have only two values:  true and false.
2. There should be only one boolean type, and it should be called "boolean" or
"bool".
3. Logical statements such as if ...  and while ... should require a boolean
expression, for example 'if (i==1) {}' .
*****************************************************************************

Reality as I see it
1. It seems quite apparent to me that any language that violates rule 3 is
subject to the most insidious type errors that compilers are supposed to catch,
for example:
while aChoice do {something};

You thought aChoice was boolean, but maybe it's not!  What happened to type safety?

2. Another example:
if (i=3) {...}  //Typing error causes infinite loop.  Compiler is clueless.

3. Arithmetic on boolean variables is mind-boggling.  What use is a boolean variable that can have values of true, false, or 99?  It may seem simple to you, but it can require quite a bit of deciphering to someone who didn't write the code.  Some of you have asked, "What's the big deal?".  It has already been shown that if it can be done, someone will want to do it, and someone else will have trouble deciphering it.

I've been programming a fair amount for about 20 years.  I have never seen a logical operation that couldn't be accomplished simply and with clarity by adhering to the above principles.  If any of these principles is incompatible with existing code in some preexisting language, well, so be it.  Maybe it's time to break it.  Apparently I'm not alone in my opinion.

As for practical matters such as speed, I don't care how boolean variables are implemented internally, whether a boolean is a bit or a byte, if true is 0 or 1, whether it's compared to 0 or whatever.  Is it not possible to create efficient code with boolean type safety?

On Thu, 3 Jun 2004 23:39:37 +0000 (UTC), Rex Couture <Rex_member@pathlink.com> wrote:

> May I interject with an opinion from an outsider?.  You all live and breath
> programming, I suppose with a fairly limited number of languages.  As a
> scientist, I use programming seriously as a tool that must be as reliable as
> possible.  I only program part time, and I often have to read, decipher, and
> write code in multiple languages.  Generally, they are so diverse and so full of
> quirks and cute tricks that this is sometimes quite challenging, to say the
> least.
>
> If you really want to expand the usefulness of D, you need to exert constant
> effort keep it simple and don't get fancy.  What I see in the boolean debate is
> anything but simple.  Let me reiterate a couple of principles (or opinions, if
> you like) that you have heard many times, and then add some comment on some
> obvious(?) pitfalls.
>
> *****************************************************************************
> 1. A boolean type should have only two values:  true and false.
> 2. There should be only one boolean type, and it should be called "boolean" or
> "bool".
> 3. Logical statements such as if ...  and while ... should require a boolean
> expression, for example 'if (i==1) {}' .
> *****************************************************************************
>
> Reality as I see it
> 1. It seems quite apparent to me that any language that violates rule 3 is
> subject to the most insidious type errors that compilers are supposed to catch,
> for example:
> while aChoice do {something};
>
> You thought aChoice was boolean, but maybe it's not!  What happened to type
> safety?
>
> 2. Another example:
> if (i=3) {...}  //Typing error causes infinite loop.  Compiler is clueless.
>
> 3. Arithmetic on boolean variables is mind-boggling.  What use is a boolean
> variable that can have values of true, false, or 99?  It may seem simple to you,
> but it can require quite a bit of deciphering to someone who didn't write the
> code.  Some of you have asked, "What's the big deal?".  It has already been
> shown that if it can be done, someone will want to do it, and someone else will
> have trouble deciphering it.
>
> I've been programming a fair amount for about 20 years.  I have never seen a
> logical operation that couldn't be accomplished simply and with clarity by
> adhering to the above principles.  If any of these principles is incompatible
> with existing code in some preexisting language, well, so be it.  Maybe it's
> time to break it.  Apparently I'm not alone in my opinion.
>
> As for practical matters such as speed, I don't care how boolean variables are
> implemented internally, whether a boolean is a bit or a byte, if true is 0 or 1,
> whether it's compared to 0 or whatever.  Is it not possible to create efficient
> code with boolean type safety?
>
>

Rex: Very well said, take a look at a post by "Kris" entitled "The very last thing(s) I'll say about bool is ..." this and that post are very similar. IMO you're both correct.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

I'm bored enough with bool 10 years ago <g>.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c9mucl$26qj$1@digitaldaemon.com...
> It'd be boring any other way, don't ya think? <g>
>
> "Walter" <newshound@digitalmars.com> wrote in message news:c9mnfn$1tc9$1@digitaldaemon.com...
> > We'll just agree to disagree, then.
> >
> >
>
>

Matthew wrote:

> Your characterisation is, if not entirely satire, disengenuous.

Yes, it was satire. But with a grain of truth, maybe? ;)

> Are you telling me that there's no - that's 0% - advantage to be had by using
> aliases / weak typedefs?

No, I'm saying there's 0% advantage to defining bool or boolean as an alias. You don't actually get anything other than bit or int.

If everyone defines their own bool types in their own modules, you don't gain any type safety or usability. The first question a programmer will need to ask when they see a new boolean alias is: "Is it really a bool or really an int?"

> If we are not to define our own type(def)s, then we should be using either Java
> or .NET. Is that your suggestion? Should the typedef / alias facilities be
> removed from D?

We *should* define our own aliases and typedefs. But not for bools.

James McComb

"James McComb" <alan@jamesmccomb.id.au> wrote in message news:c9onle$1p8n$1@digitaldaemon.com...
> Matthew wrote:
>
>  > Your characterisation is, if not entirely satire, disengenuous.
>
> Yes, it was satire. But with a grain of truth, maybe? ;)
>
> > Are you telling me that there's no - that's 0% - advantage to be had by using aliases / weak typedefs?
>
> No, I'm saying there's 0% advantage to defining bool or boolean as an alias. You don't actually get anything other than bit or int.

Ok, so there should be no aliases then? I disagree with that, but haven't the energy to muster argument.

Maybe you just mean no third-party bool aliases. That makes more sense, except that they are a placeholder for when/if a real boolean is bestowed upon us.

> If everyone defines their own bool types in their own modules, you don't gain any type safety or usability.

This is quite wrong. The boolean type I've defined is a typedef, and therefore there are manifest advantages that they cannot be used for erroneous conversions.

> The first question a programmer will
> need to ask when they see a new boolean alias is: "Is it really a bool
> or really an int?"

Good point.

> > If we are not to define our own type(def)s, then we should be using either
Java
> > or .NET. Is that your suggestion? Should the typedef / alias facilities be removed from D?
>
> We *should* define our own aliases and typedefs. But not for bools.

Ok. I can see the sense in that, except for the optimistic version reason given above.

Anyway, I know we're never going to get it, so I'm going to change my libs from boolean to bool, and hang the reduction of robustness. If anyone complains, I shall give them Walter's email address. <G>

Boris the Beaten

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------

"Sean Kelly" <sean@f4.ca> wrote in message news:c9o9bp$15jm$1@digitaldaemon.com...
> In article <c9o5qf$100l$1@digitaldaemon.com>, Matthew says...
> >
> >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.
>
> Yup.  I've seen the library examples and they work just fine.  I'll probably begin converting my code now to use one of those so I don't have to deal with
it
> later :)

Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)

In article <c9orb9$1uc9$1@digitaldaemon.com>, Matthew says...
>
>Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)

I haven't seen the STLSoft null, but maybe I should wait for it :)  I saw a templatized version that IIRC Scott Meyers wrote and perhaps one other.

Sean