We need to clarify if 'real' is the 'default floating point type' or not.
Ameer Armaly
ameer.armaly at furman.edu
Mon Mar 3 18:03:25 PST 2008
"Lionello Lunesu" <lionello at lunesu.remove.com> wrote in message
news:fqi8fc$241f$1 at digitalmars.com...
>D should establish some kind of politburo. A group of elders, each with his
>(..her?) own problem domain. Don should clearly govern the floating point
>aspects of D and just get to do what he thinks is best. : )
>
> To me, this 'real' problem sounds a lot like the 'int' problem: why should
> 'int' be established as the default integral type, when it is inefficient
> on 64-bit hardware (and on 16-bit, 8-bit, .... )?
>
> D's very proud of having fixed sized types, and rightly so, but there
> clearly are situations where size doesn't matter, and shouldn't matter. Of
> course, there's a minimum limit, when any smaller would just be
> ridiculous. ...uh... nevermind.
>
> So I think we should have 2 new aliases. One for a default int (at least
> 32-bit) and one for a default float (at least double). On X86/87 these new
> aliases would map to int and real respectively.
>
> Coming up with good names without silly adjectives/underscores will be
> difficult, though. I, for one, can't come up with any names that 'have it
> in them' to replace the omnipresent 'int' and 'real'...
>
I used to think fixed-size types were more optimal, but in retrospect how
often do you _really_ care about the maximum value of an int? There are
probably some, but more often than not I find myself wanting an integer
rather than an integer at least x bits wide. Maybe we just ought to make int
whatever type is fastest, and call the current int something different,
maybe dword?
Disclaimer: I haven't done much serious work in D recently, so odds are I'm
missing something.
> L.
More information about the Digitalmars-d
mailing list