cent and ucent?

[Jonathan M Davis]

On Sunday, January 29, 2012 15:31:57 H. S. Teoh wrote:
> On Sun, Jan 29, 2012 at 02:26:55PM -0800, Jonathan M Davis wrote:
> [...]
> 
> > This is one of the many reasons why I think that any language which
> > didn't define integers according to their _absolute_ size instead of
> > relative size (with the possible exception of some types which vary
> > based on the machine so that you're using the most efficient integer
> > for that machine or are able to index the full memory space) made a
> > huge mistake.
> 
> IMNSHO, you need both, and I can't say I'm 100% satisfied with how D
> uses 'int' to mean 32-bit integer no matter what. The problem with C is
> that there's no built-in type for guaranteeing 32-bits (stdint.h came a
> bit too late into the picture--by then, people had already formed too
> many bad habits).
> 
> There's a time when code needs to be able to say "please give me the
> default fastest int type on the machine", and a time for code to say "I
> want the int type with exactly n bits 'cos I'm assuming specific
> properties of n-bit numbers".

In an ideal language, I'd probably go with an integer type with an unspecified 
number of bits which is used when you don't care about the size of the 
integer. It'll be whatever is fastest for the particular architecture that 
it's compiled on, and it'll probably be guaranteed to be _at least_ a 
particular size (probably 32 bits at this point) so that you don't have to 
worry about average-sized numbers not fitting. Also, you should probably have a 
type like size_t that deals with the differing sizes of  address spaces. But 
_all_ other types have a fixed size. So, you don't get this nonsense of int is 
this on that machine, and long is that, and long long is something else, etc. 
So, you use them when you need a variable to be a particular size or when you 
need a guarantee that a larger value will fit in it. The way that C did it with 
_everything_ varying is horrific IMHO.

The route of languages such as D, Java, and C# where pretty much _all_ types 
are fixed in size is _far_ better IMHO. So, if the choice is between the C/C++ 
route or the D/Java/C# route, I'm with D/Java/C# all the way. But there are 
definitely arguments for having an integral type which is the most efficient for 
whatever machine that it's compiled on, and D doesn't really have that. You'd 
probably have to use something like c_long if you really wanted that.

- Jonathan M Davis