www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bool: I surrender

reply Arcane Jill <Arcane_member pathlink.com> writes:
I give in. I'm doing the decent thing and returning "bool" everythere instead of
"Bool" - not because I think Walter's got it right, but because conflicting
standards are no good for anyone. I really *do* believe that, one day in the
future, when standards committees define what D should or should not do, "bool"
itself will be made typesafe, and that transition will of course be easier if we
all (or at least, all public APIs) use the same keyword.

Currently, however, there will have to be one exception (bah!). The exception is
opEquals(), which is defined in object.d to return an int. This is still BAD ...
as Daniel Horn discovered the other day. It seems that on Linux, == sometimes
returns a value other than 0 or 1. This could never have happened if opEquals
had been defined to return (Walter's) bool (that is, aliased to bit).

Please, please, please could opEquals() return bool, not int, for all objects.
Now we are seeing platform-dependent behavior because of this. It really should
be fixed. I can't imagine why opEquals() would want to return an int. I'm
assuming it was a mistake, but Walter, if there's a good reason for it, please
could you clarify for me what that reason is?

Arcane Jill
Jun 03 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9p65n$2e8e$1 digitaldaemon.com...

 Please, please, please could opEquals() return bool, not int, for all


objects.

 Now we are seeing platform-dependent behavior because of this. It really


should

 be fixed. I can't imagine why opEquals() would want to return an int. I'm
 assuming it was a mistake, but Walter, if there's a good reason for it,


please

 could you clarify for me what that reason is?


The reason is runtime efficiency, as described in my reply to your posting
"Efficiency test for various boolean strategies." opEquals() has the
potential to be a huge performance bottleneck for sorting and searching
algorithms, so defining it so it can be implemented as efficiently as
possible is important.
Jun 04 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
Tell me, if n is an int, what does (cast(bool)n) do, exactly?

Does it do (n & 1), in the same way that (cast(ubyte)n) does (n & 0xFF)? Or does
it do (n==0 ? 0 : 1). In other words, does it truncate like ints, or saturate
like floats?

I haven't seen a definition anywhere, and if opEquals() is allowed to return
non-0, non-1 values (even by accident) it would be useful to know that casting
to bool is always going to do the right thing.

Jill
Jun 04 2004
next sibling parent Ilya Minkov <Ilya_member pathlink.com> writes:
In article <c9p965$2kcb$1 digitaldaemon.com>, Arcane Jill says...


I haven't seen a definition anywhere, and if opEquals() is allowed to return
non-0, non-1 values (even by accident) it would be useful to know that casting
to bool is always going to do the right thing.


Casting integer to bool returns false for 0, otherwise it returns true, to be
consistent with C semantics. Same convention applies when short-cut operators
are executed on integers.

-eye
Jun 04 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9p965$2kcb$1 digitaldaemon.com...

 Tell me, if n is an int, what does (cast(bool)n) do, exactly?


n?1:0
Jun 04 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Walter wrote:


 
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:c9p965$2kcb$1 digitaldaemon.com...

 Tell me, if n is an int, what does (cast(bool)n) do, exactly?


 
 n?1:0


Now, this seems like a language inconsistency to me: if bit is supposed to
be an integer type of length one bit, then it should actually cast like the
other integer types, i.e. by masking the original value.

if
        (cast(ubyte)n) == (n & 0xff)
then I would expect
        (cast(bit)n) == (n & 0x01)

Of course, this would have little practical use. Oh, well - guess that's
just once again the good old thing about bool vs. bit... :-)
Jun 07 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Walter schrieb:


be fixed. I can't imagine why opEquals() would want to return an int. I'm
assuming it was a mistake, but Walter, if there's a good reason for it, please
could you clarify for me what that reason is?


 
 
 The reason is runtime efficiency, as described in my reply to your posting
 "Efficiency test for various boolean strategies." opEquals() has the
 potential to be a huge performance bottleneck for sorting and searching
 algorithms, so defining it so it can be implemented as efficiently as
 possible is important.


Is there any chance that you change that to bit, and make a compiler 
provosion that would e.g. always hand bit as int when it is used as a 
return value to a back end? Perhaps bit should always be stored in an 
int storage instead of a byte storage, except for within structs and as 
bit arrays, where multiple adjacent bits would complement each other to 
bytes? Wasn't it your argumentation that code should follow principles 
of expressiveness, and it's compiler's work to take care of efficiency?

I'm not sure where the storage size becomes relevant to performance. If 
i remember correctly from fog's pentopt, on modern processors mostly 
alignment is important. Is there anything else causing the penalty?

-eye
Jun 04 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ilya Minkov wrote:


 Walter schrieb:


 be fixed. I can't imagine why opEquals() would want to return an 
 int. I'm
 assuming it was a mistake, but Walter, if there's a good reason for 
 it, please
 could you clarify for me what that reason is?




 The reason is runtime efficiency, as described in my reply to your 
 posting
 "Efficiency test for various boolean strategies." opEquals() has the
 potential to be a huge performance bottleneck for sorting and searching
 algorithms, so defining it so it can be implemented as efficiently as
 possible is important.



 Is there any chance that you change that to bit, and make a compiler 
 provosion that would e.g. always hand bit as int when it is used as a 
 return value to a back end? Perhaps bit should always be stored in an 
 int storage instead of a byte storage, except for within structs and 
 as bit arrays, where multiple adjacent bits would complement each 
 other to bytes?


I'd make that
except for within structs, multiple function parameters and as bit arrays,

I guess the way bit is defined now makes it possible for D vendors to 
optimise it however they want.  Of couse dmd is the major D vendor at 
the moment and I would hope that dmd will one day include these types of 
optimisations.

I think the more details you provide to the compiler about what you are 
doing the better it should be able to optimise your code.  If you only 
need a bit, you should use a bit and the compiler should worry about 
making optimisations on that type.  Since the compiler knows that a bit 
will only ever be on or off, then it should be able to use that to its 
advantage, not to its determent.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jun 04 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
FWIW, I totally changed my stance on the "bool" issue this morning.  I realized
my complaints were all due to semantics.  To me, "bool" purely describes
behavior, and I've been basing my expectations based on my experience with
C/C++.  "bit," however, is a far more descriptive term.  It describes both
behavior and storage, and is far more clear to me than "bool."  Simply put, I
have no issues at all with the current behavior of the bit datatype.  But if I
had my druthers we'd just do away with the bool alias and make a clean break
with the past... which probably puts me in the minority on this list :)

I do think that Phobos should document its interfaces using "bit" however.
Mixing both terms seems inconsistent and slightly confusing to newcomers, and
invites problems on the off chance that the definition of "bool" ever changes.

Sean
Jun 07 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Sean Kelly wrote:

 FWIW, I totally changed my stance on the "bool" issue this morning.  I realized
 my complaints were all due to semantics.  To me, "bool" purely describes
 behavior, and I've been basing my expectations based on my experience with
 C/C++.  "bit," however, is a far more descriptive term.  It describes both
 behavior and storage, and is far more clear to me than "bool."  Simply put, I
 have no issues at all with the current behavior of the bit datatype.  But if I
 had my druthers we'd just do away with the bool alias and make a clean break
 with the past... which probably puts me in the minority on this list :)
 
 I do think that Phobos should document its interfaces using "bit" however.
 Mixing both terms seems inconsistent and slightly confusing to newcomers, and
 invites problems on the off chance that the definition of "bool" ever changes.
 
 Sean


I also fail to see the advantage of the bool alias. It seems 
inconsistent with the separation of language and library. Since bit is 
part of the language, why should we need to call the same thing "bool"? 
Perhaps bit is a naughty word in someone's culture, but it seems like an 
invitation to confusion to hide a subtle alias in object.d. (Of course, 
I'm also in favor of removing printf/wprintf from object.d.)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jun 07 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:


 I also fail to see the advantage of the bool alias. It seems 
 inconsistent with the separation of language and library. Since bit is 
 part of the language, why should we need to call the same thing 
 "bool"? Perhaps bit is a naughty word in someone's culture, but it 
 seems like an invitation to confusion to hide a subtle alias in 
 object.d. (Of course, I'm also in favor of removing printf/wprintf 
 from object.d.)



Yeah, it seems strange.  I guess it makes porting easier but we could 
just as well do a find/replace and learning for beginners.

Parhaps Walter plans to pull a fast one on us and switch the bool to 
some other type when we're not looking.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jun 07 2004
parent J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:

 J C Calvarese wrote:
 

 I also fail to see the advantage of the bool alias. It seems 
 inconsistent with the separation of language and library. Since bit is 
 part of the language, why should we need to call the same thing 
 "bool"? Perhaps bit is a naughty word in someone's culture, but it 
 seems like an invitation to confusion to hide a subtle alias in 
 object.d. (Of course, I'm also in favor of removing printf/wprintf 
 from object.d.)


 
 
 
 Yeah, it seems strange.  I guess it makes porting easier but we could 
 just as well do a find/replace and learning for beginners.
 
 Parhaps Walter plans to pull a fast one on us and switch the bool to 
 some other type when we're not looking.


That's kind of what I'm hoping and/or afraid of.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Jun 07 2004
prev sibling parent James McComb <alan jamesmccomb.id.au> writes:
Sean Kelly wrote:


 ... But if I
 had my druthers we'd just do away with the bool alias and make a clean break
 with the past... which probably puts me in the minority on this list :)


I agree with you. I call it the Just Use Bit view.


 I do think that Phobos should document its interfaces using "bit" however.
 Mixing both terms seems inconsistent and slightly confusing to newcomers, and
 invites problems on the off chance that the definition of "bool" ever changes.


It looks like D will be stuck with the problem of some people using bit 
and other people using bool with no consistency. Oh well. Maybe Walter 
should make bool and boolean reserved words? ;)

James
Jun 07 2004