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