Reply to James,

> (And yes, I feel guilty/contaminated if I ever treat a boolean value
> as an integer, or vice versa.)
> 


a while ago I wrote a peice of C++ like this

start:

///

goto {&&start, &&stop}[!!i + 2 * !j];
stop:

but then again it was for a bad code contest

Reply to Walter,

> 
> c += 'a' - 'A';   // to lower case

this is safer and faster (Ihink)

c |= 0b0010_0000;

BCS wrote:
> Reply to Walter,
> 
>>
>> c += 'a' - 'A';   // to lower case
> 
> this is safer and faster (Ihink)
> 
> c |= 0b0010_0000;

Walter's version works on any platform where upper and lower case letters have the same arrangement, including any gaps; yours is pretty much tied to ASCII and extensions thereof.

(On the other hand, yours is idempotent, whereas Walter's depends on knowing that c started as upper case.)

-- James

Reply to James,

> Walter's version works on any platform where upper and lower case
> letters have the same arrangement, including any gaps; yours is pretty
> much tied to ASCII and extensions thereof.
>

good point, OTOH how often are non ASCII derived systems used (I've heard of a few but never run into any)

> (On the other hand, yours is idempotent, whereas Walter's depends on
> knowing that c started as upper case.)
> 

BCS wrote:
> Reply to James,
> 
>> Walter's version works on any platform where upper and lower case letters have the same arrangement, including any gaps; yours is pretty much tied to ASCII and extensions thereof.
>>
> 
> good point, OTOH how often are non ASCII derived systems used (I've heard of a few but never run into any)

With D, at present, probably none.  Some mainframes and
some embedded environments are the only remaining ones
I know about (though my knowledge is, of course, a long
long way from being encyclopedic.)

-- James

James Dennett wrote:
> BCS wrote:
>> Reply to James,
>>
>>> Walter's version works on any platform where upper and lower case
>>> letters have the same arrangement, including any gaps; yours is pretty
>>> much tied to ASCII and extensions thereof.
>>>
>> good point, OTOH how often are non ASCII derived systems used (I've
>> heard of a few but never run into any)
> 
> With D, at present, probably none.  Some mainframes and
> some embedded environments are the only remaining ones
> I know about (though my knowledge is, of course, a long
> long way from being encyclopedic.)

But both simple schemes for lowercasing will fail on things like accented characters.  Seeing tricks like that just to avoid calling tolower() makes me cringe.

--bb

James Dennett wrote:
> BCS wrote:
>> [...]
> [...]
> (On the other hand, yours is idempotent, whereas Walter's
> depends on knowing that c started as upper case.)

Wow, idempotent!
I last read that word studying fuzzy logic! ;-)))

Regards, Frank

Kirk McDonald wrote:
> Pragma wrote:
>> Kirk McDonald wrote:
>>
>>> Walter Bright wrote:
>>>
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.019.zip
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>> http://ftp.digitalmars.com/dmd.2.003.zip
>>>
>>>
>>> Well, this __traits stuff is certainly going to give me something to think about. One note: the lexical page doesn't seem to list it as a keyword.
>>>
>>> How many times have I rewritten Pyd? Three? Well, no matter. This should make things interesting again.
>>>
>>
>> Kirk, I saw your blog post regarding this.  Congrats.  Looks like you had a bumper-crop of code reductions!
>>
> 
> The linked-to changeset was from last November, when D got tuples. I haven't committed anything using __traits, yet.
> 

D'oh.  Shoulda read more carefully... ;)

-- 
- EricAnderton at yahoo

BCS wrote:
> Reply to 0ffh,
> 
>> If I know that testing a condition is nothing but comparing a number
>> to zero, writing "if (number!=0)" just becomes redundant.
> 
> actually ASM usually has built in >, < and = comparisons, some times these implicitly use 0 for the other side, but it still it is not /just/ a zero test.

Forgive me if I am being thick, but given C (or even D), when does
"if (x!=0)" (or "if (x!=null)") ever give a different result from "if (x)"?
I am naturally speaking integral types and pointers, for floating point
numbers the resulting code will obviously depend on the specific format
used (though compilers will usually make it to act as expected, but I know
I have to /know/, not assume).

As to why "if (x)" is (at least historically) a Good Thing (tm):
If "x" is any kind of calculation, that calculation will usually implicitly
set (or clear) the zero flag of the CPU, doing away with the need for any
kind of comparison at all. On some machines just loading the value of a
memory location into a register will work the zero flag. On many, doing
something like OR or AND of the register against itself will do the trick
a bit faster than actually comparing against any number (including zero).
On the x86, at some point of time, TESTing a memory location was faster
than CMPing it (with a very pinch-of-salty IIRC).
Especially "while" does usually gain some benefit from those cases.
(And of cause a good back end optimisation will still exploit those because
it knows that the "(x!=0)" is the same special case as the "(x)", granted.)

So my defense is reduced to it being a good and useful convention, as I cherish every keystroke I don't have to execute, and it's really easy to
learn and get used to... and, above all else, it /looks/ better! ;-)

Regards, Frank

Reply to 0ffh,

> BCS wrote:
> 
>> Reply to 0ffh,
>> 
>>> If I know that testing a condition is nothing but comparing a number
>>> to zero, writing "if (number!=0)" just becomes redundant.
>>> 
>> actually ASM usually has built in >, < and = comparisons, some times
>> these implicitly use 0 for the other side, but it still it is not
>> /just/ a zero test.
>> 
> Forgive me if I am being thick, but given C (or even D), when does
> "if (x!=0)" (or "if (x!=null)") ever give a different result from "if
> (x)"?

Never to my understanding. However this is a good reason to do the more verbose one in that the compiler gets more info and then can use that for optimization (maybe). That however is more of a general rule rather than just for this case.