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


On modern processors, there is no speed difference between the two. I prefer the former only because I can't remember which bit it is <g>.

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)

D kind of explicitly abandons things like EBCDIC anyway.

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

Walter Bright wrote:
> BCS wrote:
>> Reply to Walter,
>>
>>>
>>> c += 'a' - 'A';   // to lower case
>>
>> this is safer and faster (Ihink)
>>
>> c |= 0b0010_0000;
> 
> 
> On modern processors, there is no speed difference between the two. I prefer the former only because I can't remember which bit it is <g>.

Well, that's easy:
---
c |= 'a' ^ 'A';
---
:P

Of course, then you'd have to remember whether the bit should be 1 or 0...


And of course both methods will screw up for a lot of characters that aren't latin letters.

Reply to Walter,

> BCS wrote:
> 
>> Reply to Walter,
>> 
>>> c += 'a' - 'A';   // to lower case
>>> 
>> this is safer and faster (Ihink)
>> 
>> c |= 0b0010_0000;
>> 
> On modern processors, there is no speed difference between the two. I
> prefer the former only because I can't remember which bit it is <g>.
> 

Odd, I use \dmd\html\d\ascii-table.html to rememeber

BCS wrote:
> Reply to 0ffh,
>> BCS wrote:
>>> Reply to 0ffh,
>>>> [...]
>>> [...]
>> [...]
> 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).

Well, if we agree the semantics are identical, then so is the info the
compiler has (phew, I'm glad that this works both ways...).

> That however is more of a general rule rather than just for this case.

I accept it as a general rule. =)

Kind regards, Frank

0ffh wrote:
> 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! ;-)))

Yes, a fancy word, indeed.

OTOH, it's as important as "equivalence" and "implies".

0ffh Wrote:

> BCS wrote:
> > Reply to 0ffh,
> >> BCS wrote:
> >>> Reply to 0ffh,
> >>>> [...]
> >>> [...]
> >> [...]
> > 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).
> 
> Well, if we agree the semantics are identical, then so is the info the compiler has (phew, I'm glad that this works both ways...).
> 
>  > That however is more of a general rule rather than just for this case.
> 
> I accept it as a general rule. =)
> 
> Kind regards, Frank

There was a discussion of this on digitalmars.D recently. While that syntax works fine for most cases, it doesn't work in (non-static) asserts for aggregate types with invariants: assert(obj) runs the object's invariant() method, which will segfault if the object is null instead of giving a nice assertion failure.

"if(x != 0)" is just more explicit than "if(x)", but not many people use "if(b != false)" (unless you're that guy where I wrote who wrote "while(m_userSubscribed == Boolean.FALSE.booleanValue())", which I sincerely hope wasn't sincere), so being concise isn't bad as long as you're meaning is clear. I think it looks ugly in for loops, though:

for(int i = 100; i; i--) // Takes a second to mentally figure out what's going on

> goto {&&start, &&stop}[!!i + 2 * !j];
*Sigh*. I wish we had those GNU 'label as value' extensions in D

 - Paul

BCS wrote:
> Odd, I use \dmd\html\d\ascii-table.html to rememeber

I wrote that because I was tired of googling for "ascii table" and then getting one filled with popups.

Walter Bright escribió:
> Carlos Santander wrote:
>> How can we check specific overloads with __traits? For example,
>>
>> class A
>> {
>>     abstract void foo();
>>     int foo(int i) { return i; }
>> }
>>
>> void main ()
>> {
>>     auto isvirtual = __traits(isAbstractFunction, A.foo); // what is it?
>> }
> 
> You'll need to split them apart with getVirtualFunctions, or cast the A.foo.
> 

As for getVirtualFunctions, I'm guessing abstract foo would not be virtual, and the other one would. Am I right?

As for casting, cast A.foo to what?

-- 
Carlos Santander Bernal