On 8/13/11 7:20 AM, Lars T. Kyllingstad wrote:
On Thu, 11 Aug 2011 00:27:54 -0700, Jonathan M Davis wrote:
On Thursday, August 11, 2011 07:10:08 Lars T. Kyllingstad wrote:
On Wed, 10 Aug 2011 12:37:01 -0600, Andrei Alexandrescu wrote:
* filenameCharCmp and filenameCmp -> why long and not int?
filenameCharCmp() returns a-b, and since a and b are dchars, the
corresponding signed type is long. filenameCmp() returns long because
filenameCharCmp() does.
I'd argue that you should just cast it to int and return int. All the
various compare functions promise is whether the return value is less
than, equal to, or greater than 0. Relying on the exact value is wrong.
And normally such functions return int. So, I don't see any reason why
these shouldn't be change to return int.
But what do we gain by making it an int? long just seems more natural in
this case, IMO.
Unicode characters range in between 0 through 1,114,111. So the most
natural type of the difference is int.
This would be the first time I'm seeing an API returning a ternary value
as a long.
(Also, 64-bit machines can operate on two 32-bit integrals
simultaneously (literally) so 32-bit integrals may be faster. Probably
not a material advantage.)
Andrei
