🚀 go-pugleaf

In article <3ve4po$pm7@caip.rutgers.edu> halasz@caip.rutgers.edu writes:
> In article <3vbmks$25u@newsbf02.news.aol.com>, ffarance@aol.com (FFarance) writes
>> 	signed int atleast:(EIR_LG2CEIL(1.0E18)+1) x;
> I will not uze a C that requires me to write this,

It *requires* nothing of the sort.  It *offers* the possibility, if you
want it.

> for nothing in integers
> in C is needed beyond seeking a range of integers, in the shortest type
> that the processor nativlie well handles.

Huh?  What do you use C for?  I think I use it for something else.
(I assume "processor nativlie" means "native processor").

> (...) I also want to know the characteristics of the 'int' that I got:
> hou long,

Yes, I too would like EIR_SIZE(precof(i)) == sizeof(i).

> what its actual upper and lower bound are,

It's there.  See Frank Farance's paper:

       EIR_MAX(precof(type)) max value of `type'
       EIR_BIT(precof(type)) number of bits of actual precision for `type'.

> and so on (note that most of your precizion-machinerie is excluded).

Check the other EIR_* macros.

>> You can't manipulate
>> the typedefs in the preprocessor (e.g., "sizeof" or cast operator) because
>> (1) the preprocessor doesn't understand this,
> I want "sizeof", &c for inbilt types and "size_t" and "ptrdiff_t"
> understood by it, even if types from "typedef" are not to be had.

sizeof(builtin type) and sizeof(builtin type *) can be done in the
preprocessor, though I don't expect it will.  &c cannot be done.

Well, you can use preprocessor to some degree already, for example,
TYPE_LIMIT(int) below expands to the value of INT_MAX.
	#include <limits.h>
	#define TYPE_LIMIT(type)	TYPE_L0(LIMITS_NAME_##type)
	#define TYPE_L0(name)		TYPE_L1(name)
	#define TYPE_L1(name)		name##_MAX
	#define LIMITS_NAME_char	CHAR
	#define LIMITS_NAME_short	SHRT
	#define LIMITS_NAME_int		INT
	#define LIMITS_NAME_long	LONG
Though I can't help you with size_t, ptrdiff_t and multi-word types like
`unsigned short'.

> I would not uze "typedef" for this.

You'd prefer the preprocessor to understand it?  So would I, but note
that if the preprocessor could expand `sizeof(int atleast:18)' -> `32'
you'd *still* have to insert `atleast:' in the language too.
(Or with some other syntax, of course).

So, sure, it would be nice if the preprocessor really understood C types
(unless you've got to implement it:-)  But this is a separate issue, and
should be treated as such.

Also, note that quite a bit of what you are doing with the preprocessor
probably can be reduced to `if (0) ... else ...' and can be done just as
well by the compiler's optimizer.

> All this 'int'-stuff is too much junk.  I would not program in a C that had
> more than I suggest, for the rest is mere fat, to encumber the implementor
> and the programmer.  Nor want I the like for floatind-point, on the same
> grounds.  This is for another, new programming language to your taste, not C.

Encumber the implementor, yes.  The programmer, no.  If you don't like
it, you don't have to use it.

You just don't think this is useful enough to warrant a change in the
language?  That's a reasonable point of view, of course.  But then you
can certainly forget your `return parameter' request too, that doesn't
even add anything to the language which can't be done already.
-- 
Regards,

Hallvard