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