64 bit architectures and C/C++

[Richard A. O'Keefe]

In article <TMB.91May3225038 at volterra.ai.mit.edu>, tmb at ai.mit.edu (Thomas M. Breuel) writes:
>    I am greatly disappointed that C++, having added so much to C, has not
>    added something like int(Low,High) to the language, which would stand
>    for the "most efficient" available integral type in which both Low and
>    High were representable.  The ANSI C committee were right not to add
>    such a construct to C, because their charter was to standardise, not
>    innovate.
> 
> I think allowing the programmer to specify arbitrary precision
> integers is equally bad, since it adds too much complexity to
> the language and to compilers.

But nowhere did I suggest "allowing the programmer to specify arbitrary
precision integers".  Read what I wrote: the compiler would select "the
most efficient AVAILABLE integral type in which both Low and High were
representable".  I'm not talking about increasing the stock of integral
types built into the compiler, simply talking about a way of selecting
one of those types.  For any given copy of <limits.h> I can define an
M4 macro
	selected_integral_type(Low,High)
which expands to char,short,int,long, &c.  Indeed, I believe I posted
such a macro to this group last year.  My point is that this could have
been built into the compiler TRIVIALLY.  I really do mean "trivially";
we are talking about adding one 10-line function to a C compiler, plus
a couple of productions in a Yacc grammar.

What I was asking for is _less_ than what Pascal provides!

-- 
Bad things happen periodically, and they're going to happen to somebody.
Why not you?					-- John Allen Paulos.