Re: Malcolm's new book
- From: Kelsey Bjarnason <kbjarnason@xxxxxxxxx>
- Date: Fri, 03 Aug 2007 19:08:08 GMT
[snips]
On Fri, 03 Aug 2007 07:18:13 +0100, Malcolm McLean wrote:
size_t didn't use to be part of the language. It's a relatively new
invention designed to solve the problem of memory buffers bigger than the
range of an int. Of course such buffers should seldom arise, if you obey the
convention that int is the "natural" integer size of the machine.
How about obeying the convention that C defines its rules and they're
defined for good reasons, so one should pay attention to them?
If we allow that any array can overflow the size of an int we get the
folowing
void payroll(struct Employee *emplloyees, size_t N)
{
size_t i;
for(i=0;i<N;i++)
/* so something */
}
Now N is arguably a size, though it is a slightly confusing term.
Actually, it's a count, but either way.
However the type of i is downright misleading. It does not hold a size
at all.
In fact this won't be acceptable, and something will be done.
Huh? You're not using it as a size, so something isn't acceptable?
Either size_t will have to be deprecated / quietly dropped, or C itself
will be regarded as an "advanced" language unsuitable for beginners, and
gradually be squeezed out.
A language is a tool and a tool takes practice to master. If C is too
hard, you should stick to BASIC.
size_t is a kludge, and code is clearer without it.
The code in the example chapters is neither clearer nor good; it is broken
by design, because the author doesn't grasp basic concepts.
Simple example: using size_t to specify the size of the buffer to compress
makes sense; the buffer size will be 0..N. Using int makes it *less*
clear:: the developer obviously intended to allow negative values
specifying the length of the buffer; if he hadn't, he wouldn't be using a
plain int, he'd be using the proper type: size_t. Since he *is* expecting
negative values, the actual intent of the function is no longer clear, as
you cannot compress (or even create) a negatively-sized buffer, so there
must be a special meaning to such negative values, so let's haul out the
reference manual to see what the heck the code does in such cases.
Meanwhile we now have to also worry that our buffer might be too big and
overflow the length parameter, despite there being not a single good
reason for such a case to ever exist with properly-written code that uses
the proper types.
Yeah, sure makes it clearer.
It has no place in
my book,
"It" being "good coding practice".
If you disagree with this choice, I include an example of "real" code,
an atan2 routine form Sun, so that the reader has some exposure to what
production code can look like.
I assume it's ugly. All I can say is I'll take ugly code that works over
pretty code that's broken, any day.
.
- Follow-Ups:
- Re: Malcolm's new book
- From: Richard Heathfield
- Re: Malcolm's new book
- References:
- Re: Malcolm's new book
- From: Kelsey Bjarnason
- Re: Malcolm's new book
- From: Malcolm McLean
- Re: Malcolm's new book
- From: Kelsey Bjarnason
- Re: Malcolm's new book
- From: Malcolm McLean
- Re: Malcolm's new book
- Prev by Date: Re: Second largest
- Next by Date: Re: A good compiler
- Previous by thread: Re: Malcolm's new book
- Next by thread: Re: Malcolm's new book
- Index(es):
Relevant Pages
|