Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!samsung!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: 64 bit architectures and C/C++ Message-ID: <5664@goanna.cs.rmit.oz.au> Date: 9 May 91 04:27:14 GMT References: <168@shasta.Stanford.EDU> <4068@inews.intel.com> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 31 In article , tmb@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 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.