On Thursday, 23 January 2014 at 14:40:58 UTC, bearophile wrote:
Dominikus Dittes Scherkl:
E.g. "ubyte abs(byte)" - this functions which can't even use a
template, or has anybody a good idea ho to express
"unsigned T abs(T)(T x)"?
I think this is not hard to do in D.
Not hard. But very ugly.
How would you express "the corresponding type of same size but
unsigned?"
But anyway, this is not what I wanted to do.
by the way: why wasn't "short" instead called "word"?
On most modern CPUs a word is longer than a short.
I know. In C "int" was meant to be the machine word. But as 32bit
machines became common everybody assumes int to be 32bit (which
made
lots of code defective) and still used "word" to refer to 16bit
types.
Its only I'd love to have a "sword" type in D :-D
It worked all well until I found that the new operators !<>
!<= etc can't be overloaded (they are only available for
floating types)! Why is this so?
D made all the floating point stuff so much better than C, but
the integral types still suffer the same old flaws.
Those FP operators are about to be deprecated. Apparently they
add too much complexity for what they offer. using
std.math.isNan should suffice.
Ok. Good to know. "isNan" is easy to implement for my new type.
But for FP - aren't there more values which the special operators
take care of?
Infinity, negative zero, values near zero etc?
Hmm - ok, std.math contains them all.
But apperently the abs() function implemented there makes exactly
the
above mentioned error:
abs(-128) = -128 because it returns the same type as the input
has.
I hate standard functions that produce bogous results.
This is why I think we would be better off with symmetric signed
types.
Would also provide a perfect init value just like FP: NaN.
Ok, it costs some performance, but for that I would always prefer
unsigned types where you can do all the bit-fiddling shift and
overflow-with-carry-bit
(oh, wait: this is also not available in D. Why?!? Pretty much
every processor has it and its available in about every assembler
I've ever seen. Why not in D?)
From signed types I expect reasonable performance but save
operations (e.g. everything that produces over or underflow
should deliver NaN and not arbitrary garbage)
