DMD 0.148 release
Regan Heath
regan at netwin.co.nz
Sun Feb 26 16:16:53 PST 2006
On Mon, 27 Feb 2006 00:32:25 +0100, Ivan Senji
<ivan.senji_REMOVE_ at _THIS__gmail.com> wrote:
> Regan Heath wrote:
>> On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek at psych.ward>
>> wrote:
>>
>>> On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan at netwin.co.nz>
>>> wrote:
>>>
>>>> On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
>>>> <thomas-dloop at kuehne.cn> wrote:
>>>>
>>>>> Charles schrieb am 2006-02-26:
>>>>>
>>>>>>
>>>>>> > Can't we simply treat zero as false and non-zero as true as we C
>>>>>> > programmers always do?
>>>>>>
>>>>>> I agree, I still don't get what the 'true bool' fuss is about .
>>>>>
>>>>>
>>>>> if(b==1) { ... }
>>>>>
>>>>> instead of
>>>>>
>>>>> if(b!=0) { ... }
>>>>>
>>>>> can be found in quite a lot of C code ...
>>>>
>>>>
>>>> So?
>>>>
>>>> Assuming:
>>>>
>>>> - 'b' is a bool
>>>> - a bool can only have 2 values, 'true' and 'false'
>>>> - when you convert/promote a bool to an int you get: 'true'->'1',
>>>> 'false'->'0'
>>>> - when you convert/promote an int to bool you get: '0'->false,
>>>> '!0'->'true'
>>>>
>>>> Then:
>>>>
>>>> if(b==1) { ... }
>>>>
>>>> results in 'b' being converted to int, giving it the value 1, and
>>>> the comparrison working correctly.
>>>>
>>>> Right?
>>>
>>>
>>> If it implemented that way, yes. However the problem with
>>>
>>> if(b == 1)
>>>
>>> is that the reader (future maintainer) might be mislead into thinking
>>> that 'b' is an integer and may try to use it as such by mistake. It
>>> is better to inform the reader about the true nature of 'b' by writing
>>>
>>> if (b == true)
>>>
>>> in or to remove such ambiguity.
>> Sure, but the example was old C code, presumably copied into a D
>> source file and used. Or perhaps a C programmer not used to having
>> bool using '1' for true. I was just pointing out that it was likely to
>> work, not that it was as clear as it could be.
>
> I usually want my code not only to likely work. That is just not enough.
By "likely" I actually meant it "will definately" work provided it is
implemented in the way in which it is "likely" to be implemented. In other
words, if it's done how I think it will be done, it "will" work fine.
> What if someone writes D compiler for a strange CPU on which parity
> instructions are faster than comparing to 0 or 1, then we could have
> "true" == more zeros, "false" == more ones.
>
> Or there could be any other imaginable implementation of bools and each
> and every one will break on code like if(b==1), if(b==0), while(b),
> if(3)...
All that is "possible" if not "likely".
Regan
More information about the Digitalmars-d-announce
mailing list