Re: Implicit int
- From: anw@xxxxxxxxxxxxxxxx (Dr A. N. Walker)
- Date: 31 Jul 2007 17:14:42 GMT
In article <f_OdnThMeesf3jLb4p2dnAA@xxxxxx>,
Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:
Chacun a son gout, but I'm surprised that anyone finds them<shrug> Not my problem. :-) I am speaking from a user's perspective,
oppressive, or even neutral. It's not as though they're hard to
compile or implement, or even would have been in the 1970s.
rather than an implementor's.
Well, so was I!
Let me take the three you quoted against
which I marked an E, and explain my reasoning:
Variable-length arrays: the problem here is with failure. The
introduction of VLAs does not magically increase the amount of memory
available to the program, obviously - so there inevitably comes a point
at which we can't allocate the amount we want. [...]
But this is nothing to do with VLAs. You will get the same
crunch with a fixed-length array if the length is too big and the
declaration is, eg, inside a deeply recursive procedure. Meanwhile
note that if you can't declare an array of size "n", then you must
declare one of size 1048576 [or whatever] that you have magically
decided is bigger than any possible "n", and you must then keep
testing your indices against "n" instead of against the actual size
of the array. This is (a) a waste of space; (b) a bug waiting to
happen when in fact "n > 1048576"; and (c) another bug lying in
wait when "i >= n" and you forgot to check -- and no bounds check
imposed by a safety-conscious compiler is going to discover this.
It's not as though all of these things have not happened time and
time again in actual C programs ....
long long int: an unnecessary wart. It does nothing that implementors
could not already do with long int, had they chosen so to do. [...]
Well, OK, but I quite like what the most recent version of
Algol has done, viz that "long long" has length determined by pragma,
but with a reasonably generous default:
Program:
LONG LONG REAL s2 = long long sqrt (2);
PROC fact = (INT i) LONG LONG INT: ( i > 1 | i * fact (i-1) | 1);
print ((s2, newline, fact (42)))
Output:
+1.4142135623730950488016887242096980785696718753769480732e +0
+1405006117752879898543142606244511569936384000000000
Not quite a "bignum", but if you want 1000-digit integers, you can get
them very easily, and all the standard operators and functions just work.
And if we *must* have a min-64-bit type, we should have called it "very
long int". :-)
OK! Or is it taking natural language programming too far?
mixed declarations and code: in my view, these make code harder to read.
I recognise that this is not a popular view, but if the declaration is
so far away from the code that it's hard to see, then the function (or
the block, at least) is probably too big anyway and should be
refactored.
It's not so much whether it's hard to see -- though that can
be a factor -- but whether declarations go in the "right place". It's
the initialiser rather than the identifier; I prefer
some long;
calculation;
int i = the result;
to
int i;
some long;
calculation;
i = the result;
as it not only saves a line but also saves you a possible bug from
using "i" before it is initialised. [Also better if "i" is constant,
of course.]
[There is still a way to go, of course, before C becomes ReallyOne of the very few temptations C++ has to offer that I find hard to
Useful .... I suppose you would classify operator declarations
somewhere around Z?]
resist is that of operator overloading, [...].
So there's hope yet?
--
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
anw@xxxxxxxxxxxxxxxx
.
- Follow-Ups:
- Re: Implicit int
- From: Richard Heathfield
- Re: Implicit int
- References:
- Implicit int
- From: Anderton J
- Re: Implicit int
- From: Richard Heathfield
- Re: Implicit int
- From: Dr A. N. Walker
- Re: Implicit int
- From: Richard Heathfield
- Implicit int
- Prev by Date: Re: Structure definitions in XML
- Next by Date: Re: Implicit int
- Previous by thread: Re: Implicit int
- Next by thread: Re: Implicit int
- Index(es):
Relevant Pages
|
