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