-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jack said:
Hi,
could somebody explain me this code?:
void radixsort(unsigned int *array, unsigned int size) {
int x, y, z;
unsigned int *buckets[NUM_BUCKETS];
unsigned int count[NUM_BUCKETS];
unsigned int mask;
for(x = 0; x < NUM_BUCKETS; x++) {
buckets[x] = (unsigned int *) malloc(size * sizeof(unsigned int));
The line above is poorly written for C, although it is legal unless it
happens to obscure the required diagnostic if there is no valid
prototype for malloc() in scope. If there is no prototype for
malloc() in scope, the behavior is undefined.
}
for(mask = 1; mask; mask = mask << 1) {
for(x = 0; x < NUM_BUCKETS; count[x++] = 0);
Some programmers never seem to grasp the fact that white space in C
source code does not increase either the size or execution time of the
final program.
Putting a semicolon on the end of a for loop like this is a fairly
common newbie mistake. Anyone who did that in any professional
organization with reasonable standards would be corrected.
Jack, if I read the code correctly, the semicolon is properly placed, and is not
an error or a violation of coding standards (unless your coding standards are
needlessly strict).
Consider the effect of
for(x = 0; x < NUM_BUCKETS; count[x++] = 0);
The re-initialization expression
count[x++] = 0
initializes count[x] to zero, and increments x
I completely understood the function of the code, and indeed it could
have been replaced with a call to memset() to zero the array, now that
the C standard has finally caught up with reality and required all
bits 0 to be a valid representation of 0 for all integer types.
What I was specifically referring to was the placement of the
semicolon. Often such placement is a common newbie mistake. In this
case it does indeed make logical sense given that the loop needs no
body, and given the simple nature of the code this is relatively easy
to see.
But what if the action of the loop was somewhat more complex, and you
were performing a code inspection of the code? What if it were not
immediately obvious that the loop did not need a body, and the
following statement looked at first glance like it might be the body
of the loop? How much time should a reviewer waste figuring out
whether the semicolon is a mistake, and a potentially serious defect,
or not?
Coding standards, as opposed to "style guides", are about techniques
that statistical evidence proves lead to code that is easier to
inspect, has fewer defects, and is easier to maintain.
One of the MISRA C guidelines that I agree with, and there are quite a
few that I don't, is that a null statement must stand alone on a line
by itself.
Another which might or might not be MISRA but I can't remember
offhand, is that all selection statements have their controlled code
enclosed in braces, even if it is a single statement, even a null
statement. There is plenty of statistical evidence that this will
eliminate two or three defects per 100K lined of code, if not when
written then when modified or maintained.
Under the coding guidelines of my organization, which I have a large
part in defining and enforcing, this loop would be written as:
for(x = 0; x < NUM_BUCKETS; count[x++] = 0)
{
/* comment here is optional
;
}
There is no doubt whatsoever that this is an intentionally empty body.
To me, this for() statement looks like a standard 'initialize the array to zero'
loop. It could also be expressed as
for (x = 0; x < NUM_BUCKETS; x++) count[x] = 0;
[snip]
Once upon a time source code was edited on teletypes and stored on
punch cards, paper tape, magnetic tape, floppy disks, etc. Those days
are long gone. Try to find a hard disk drive under 40 gig, a display
terminal that displays less than 50 lines by a 100 or more columns.
The lack of white space is far more expensive than its presence.
