Complex number functions for std.math

Georg Wrede georg.wrede at nospam.org
Mon Apr 10 11:00:21 PDT 2006


Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>> Ehh, if I understand this correctly, this would be the opposite from:
>>
>> Define "bitsizenames" as the ultimate "Genuine Types", and only alias 
>> them to the "usually used" types.
> 
> Yes, this would be the opposite from changing the base type names...
> 
> But all those D types (again: except for real) have a fixed size, so
> it's nothing like what you encounter in the old C headers/libraries ?
> 
> The only question is which of them is genuine and which is the alias.
> 
>> This "opposite" is what I have a problem with. I start seeing ghosts 
>> in the bedroom as soon as somebody tries to define "reality" with a 
>> set of incongruent "colloquial" names, and only then -- and as defined 
>> by them, define the "reality" types.
>>
>> I hope I've seriously misunderstood the above post.
> 
> Depends on what you read into it. It's only a pragmatic approach, based
> on the assumption that the names in the current type list won't change.
> 
> Thus, adding types with embedded bit sizes would *have* to be aliases ?
> Here was the entire list, with the floating points changed and added to:
> 
> INTEGER
> byte (8)
> short (16)
> int (32)
> long (64)
> cent (128)
> 
> FLOATING-POINT
> half (16)
> float (32)
> double (64)
> extended (80)
> quad (128)
> 
> I don't think the current D names are that bad. Similar to C and Java...
> And I don't think that they (D) are going to change, either ? Do you ?
> 
> And whether you use "int" or "int32_t", and perhaps "double" or e.g.
> "Float64", is more a matter of style and taste than of the D language ?

"911? Er, yes, can I get Ghost Busters! And don't hang up on me, please!!"



More information about the Digitalmars-d mailing list