For example:

void zero_an_array(int array[], int
size_of_array);

void zero_an_array(int array[], int
size_of_array)
{
register int i;
for (i = 0; i < size_of_array; i++)
   {
   array[i] = 0;
   }
return;
}

void zero_an_array(int array[], int size_of_array)
{
register int i;
for (i = 0; i < size_of_array; i++)
   {
   *array = 0;
   array++;
   }
return;
}

void zero_an_array(register int array[], register int size_of_array)
{
while (size_of_array--)
   {
   *array++ = 0;
   }
return;
}

If I am still concerned with performance, I can eliminate the overhead of calling a function by turning this operation into a macro, as in the following:

#define zero_an_array(array, size_of_array) \
{                                           \
register int i = size_of_array;             \
register int * p_array = array;             \
while (i--)                                 \
   {                                        \
   *p_array++ = 0;                          \
   }                                        \
}

In a recent CUJ article Dwayne Phillips reviewed the book C Elements of Style by Steve Qualline (CUJ, March 1994, p. 115). This book suggested that the following form:

*destination = *source;
destination++;
source++;

*destination++ = *source++;

#define zero_an_array(array, size_of_array) \
   memset(array, 0, size_of_array)

struct s_something
   {
   int a_member;
   ...
   };
struct s_something *p_something;
p_something = calloc(sizeof(struct s_something), 1);
...
p_something->a_member = 0;

If my design calls for an array of data objects, I typically start with a declared array. For example:

#define SIZE_ARRAY 100
int an_array[SIZE_ARRAY];
//...
int i;
for (i = 0; i < SIZE_ARRAY; i++)
   {
   an_array = i;
   }

#define SIZE_ARRAY 100
int *an_array;
int i;
an_array = calloc(sizeof(int), SIZE_ARRAY);
//...
for (i = 0; i < SIZE_ARRAY; i++)
   {
   an_array[i] = i;
   }
...
free(an_array);

Hi Ken. You may or may not remember me from a few years back. You were teaching a private C class for Chubb Life in Chattanooga, TN.

I have had some programmers (my users) complain that float/double math causes them some headaches when working with dollars and cents calculations. I seem to remember your writing an article in CUJ about this problem. You know, the one where a calculation that should render an answer of, say, 1.342989 comes out to be something like 1.342988993. These guys come from the mainframe world where packed decimal arithmetic doesn't give them this problem. You can imagine the flack I take about this. I would be eternally grateful if you could reveal the secret or at least point me to a book/magazine/scroll/etc. that has the answer.

Many thanks.

John Lee
Chattanooga TN

A

Thank you for remembering me. For the benefit of readers who've never worked on mainframes, I should probably explain that the packed decimal representation is more commonly available on these machines mainly because of the languages they support, particularly COBOL. Your problem comes from differences in the way fractions are represented in binary and decimal systems. If all you dealt with were whole numbers (that are not too big), the problem would not arise. Using fractions in programs presents two difficulties: The first difficulty is that no representation can store all possible fractions with complete accuracy; a particular representation will round or truncate some fractions and store others without error. To make matters worse, the set of "accurately representable" fractions will be different for two different systems of representation. The second, related, difficulty is that calculations performed in each representation system will give different results due to each system's unique method of rounding or truncation.

COBOL typically stores numbers and performs computations in PIC format, which is a form of decimal or packed decimal. Each byte or half-byte stores a decimal digit. Floating-point (COMP-2) numbers store values using binary representation. A decimal fraction such as 0.123 cannot be represented exactly in binary floating point.

If you performed all your calculations with COMP-2 variables rather than PIC variables, you would get the same end-of-fraction differences that you get using double variables in C.

In complex calculations the final result of using the above two forms may differ in the last digit. But even two different decimal arithmetic systems can produce inconsistencies for the same calculations if you used different rounding techniques in each or different numbers of fractional digits for intermediate results.

char * pc5    = new (char*)[n];   /* Case 5 */
char * pc6    = new (char(*))[n]; /* Case 6 */

Some readers have sent in comments. Aarne Y Rotiala of Espoo, Finland writes:

"Well, I'll say that the compiler is simply broken. I tried to repeat the (very suspicious) allocation. Here's what I tried on a Sun Sparc 10, running SunOS4.1:

#include <stdio.h>

int main( int argc, char * argv[])
{
   char *p0, * p1, * p2, * p3, * p4;
   p0 = new char [10];
   p1 = new char * [10];
   p2 = new (char (*)) [10];
   p3 = new (char *) [10];
   p4 = new (char (*)) [10];
   // empty body
}

alloc.cc:     In function 'int main(int, char **)':
alloc.cc:7:   assignment between incompatible pointer types
alloc.cc:8:   warning: ANSI C++ forbids array dimensions
              with parenthesized type
alloc.cc:8:   assignment between incompatible pointer types
alloc.cc:9:   warning: ANSI C++ forbids array dimensions
              with parenthesized type
alloc.cc:9:   assignment between incompatible pointer types
alloc.cc:10:  warning: ANSI C++ forbids array dimensions
              with parenthesized type
alloc.cc:10:  assignment between incompatible pointer types

Burt Smith of Jeffersonville, PA writes:

"I'm working with Sun C++ 2.1 (old stuff, I know), and case #6 won't compile for me — not that it is particularly relevant, since it is essentially the same as #5.

Anyway, what might clear this up is (ulp!) another set of parentheses:

char* pc5 = (new (char*))[n];
char* pc6 = (new (char(*))[n];

This is how I think the compilers are interpreting it. Arguably, this may be an incorrect interpretation on the compiler's part; I would think that the following would be more appropriate:

char* pc5a = new ((char*)[n]);   // Error: should be char** pc5a.
char* pc6a = new ((char(*))[n]); //Error: should be char** pc5b.

Without any parentheses the following is incorrect:

char* pc5b = new char*[n];   // Error!
char* pc6b = new char(*)[n]; // Error? I can't test this one.

I thank Aarne and Burt for their replies. I would agree with g++ and designate such constructions as invalid. A technical explanation for accepting the construction in the standard may exist. But if several programmers cannot determine what the declaration really means without a lot of deep thought, then I would prefer disallowing it in a company standard.