symmetric signed types

Dominikus Dittes Scherkl Dominikus.Scherkl at continental-corporation.com
Thu Jan 23 08:45:27 PST 2014


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)


More information about the Digitalmars-d mailing list