www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pragma for default literal type?

reply Norbert Nemec <Norbert Nemec-online.de> writes:
Hi there,

the idea was brought up by Georg Wrede in the "80 bit challenge" thread, 
but I think it is more general:

Why not generalize the behavior of types and literals:
* have types of exactly-defined size/precision
* alternatively have types that default to the optimum size/precision of 
the platform
* have suffixes for literals to specify exact precision
* have literals without suffix result in the default type

Now, the mapping between the default type and the exact precision should 
be done by the implementation, but there should be a pragma to change it 
by hand.

The details of the naming are a secondary topic. The following has been 
proposed, discussed and rejected over and over again. Still, together 
with the idea of making the mapping configurable via a pragma and 
coupling it with the default size of literals, it might be interesting 
to reconsider.

I would still propose to clean up the mess of C types completely and 
start from scratch:

	int8, int16, int32, int64, int128
	uint8, uint16, uint32, uint64, uint128
	float32, float64, float80, float128
	ifloat32, ifloat64, ifloat80, ifloat128
	cfloat32, cfloat64, cfloat80, cfloat128

No further explanation necessary. Any programmer coming from whatever 
language will understand intuitively without consulting a manual. (One 
has to be aware that cfloat32 has actually 64 bits, but that matter is 
awkward no matter which way you put it.)

The "optimum-size" types:
	int, real, imaginary, complex

As said, the mapping between optimum-size types and exact-size types is 
given by default by the compiler, but there should be a pragma to fix it 
on a per-source-file basis.

The fixed-size types might look ugly like hell, but they are not 
supposed to be used a lot, except in places where you need to be aware 
of exact bit-sizes. Most code will only deal with the optimum-size 
types, which is easy to be remapped if you need to work around 
compatibility issues.

This solution will do away with the awkward historical short/int/long 
and float/double/long-double confusion without just running into another 
confusion.

Compatibility with existing D code might break in some places but not 
badly. Porting C code should not be a problem: int in C never was 
cleanly defined, so any code depending on a fixed size was broken 
anyway. float and double simply don't exist anymore, so you either 
define an alias or replace them by "real".
Apr 03 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 The details of the naming are a secondary topic. The following has been
 proposed, discussed and rejected over and over again. Still, together
 with the idea of making the mapping configurable via a pragma and
 coupling it with the default size of literals, it might be interesting
 to reconsider.

 I would still propose to clean up the mess of C types completely and 
 start from scratch:
 
     int8, int16, int32, int64, int128
     uint8, uint16, uint32, uint64, uint128
     float32, float64, float80, float128
     ifloat32, ifloat64, ifloat80, ifloat128
     cfloat32, cfloat64, cfloat80, cfloat128


You could also add these Unicode types to the mess:
       utf8, utf16, utf32

BTW:
Have you looked at the DMD source code yet ?
You might want to peek at "dmd/mars.h"... :-)


 No further explanation necessary. Any programmer coming from whatever 
 language will understand intuitively without consulting a manual. (One 
 has to be aware that cfloat32 has actually 64 bits, but that matter is 
 awkward no matter which way you put it.)


I made a half-hearted attempt to reuse the stdint types
for floating point types too, but withdrew it again...

See http://www.prowiki.org/wiki4d/wiki.cgi?StdTypeAliases
It just seemed like too many people hated the _t suffix ?


 The "optimum-size" types:
     int, real, imaginary, complex


That should probably just be "integer", to avoid
a couple of decades of confusion on the matter ?
(just as real could also be "floating" or something)

You also have the "types": size_t and wchar_t, too ?
(linking to uint/ulong and wchar/dchar, respectively,
alias target depending on what the target ABI/API is)

     version (X86) alias ulong size_t;
     else version (AMD64) alias uint size_t;
     else static assert(0);

     version (Win32) alias wchar wchar_t;
     else version (linux) alias dchar wchar_t;
     else static assert(0);

D currently uses the CPU and OS here (a mistake, IMHO,
as it should instead be all about the ABI and the API...)


 Compatibility with existing D code might break in some places but not 
 badly. Porting C code should not be a problem: int in C never was 
 cleanly defined, so any code depending on a fixed size was broken 
 anyway. float and double simply don't exist anymore, so you either 
 define an alias or replace them by "real".


These are (IMHO) the D names-du-jour, for the above list:

      byte, short, int, long, cent
      ubyte, ushort, uint, ulong, ucent
      float, double, extended, quadruple
      ifloat, idouble, iextended, iquadruple
      cfloat, cdouble, cextended, cquadruple
      char, wchar, dchar

Mapping these two sets could be given as a quiz... ;-)
(probably right after the Mars/Phobos/Deimos question)


As long as the irreal and cereal types dies, all's well...
(but I do not like the proposed number suffixes myself, at
least not as the primary type names? I'm too used to C/Java)

--anders
Apr 03 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
     version (X86) alias ulong size_t;
     else version (AMD64) alias uint size_t;
     else static assert(0);


Oops, seems I made a small copy-and-paste error:

      version (X86) alias uint size_t;
      else version (AMD64) alias ulong size_t;
      else static assert(0);

--anders
Apr 03 2005