Ohhhhhhhhhhhhhhhhhhhhhhh


Good eyes!

Thanks.

A lot of hours spent grading students' code. Not to mention debugging my own. Of course, I can still end up spending a lot of time trying to track down my own bugs when I screw up something subtle. The fact that my eyes have gotten so bad that I have a hard time distinguishing (, from [, from {, doesn't help.

 

You must have made some other change. Changing th name of the variable is not going to fix the syntax error unless "size" is a reserved word in your compiler.

Depending on the compiler, the difference in function prototype at the top to the actual function parameters later on must match exactly, save for variable names.

int* is a pointer, while int[] is an array, both are addressed by pointers, but an integer pointer is expected to point to a single number, while int[] indicates the pointer is to an array of numbers.

 

Depending on the compiler, the difference in function prototype at the top to the actual function parameters later on must match exactly, save for variable names.

int* is a pointer, while int[] is an array, both are addressed by pointers, but an integer pointer is expected to point to a single number, while int[] indicates the pointer is to an array of numbers.

WBahn picked it up there was a size in a #define.

 

WBahn picked it up there was a size in a #define.

Woops, I left this window open way too long to realize there were more replies. Most compiler editors will highlight keywords in a different color than variables.

Finding issues with unmatched {[( is easily accomplished by running the code through the "indent" program, I know it's on *nix systems as an option, and there are ports to win32 which will add color code in addition to formatting the code.

Looking at the overall code, wouldn't it be simpler to do a for loop with step 3 then use pointer, pointer+1, and pointer+2 to index the x,y,z, each section loop? It would shorten the program up by a good deal.

 

Depending on the compiler, the difference in function prototype at the top to the actual function parameters later on must match exactly, save for variable names.

int* is a pointer, while int[] is an array, both are addressed by pointers, but an integer pointer is expected to point to a single number, while int[] indicates the pointer is to an array of numbers.

Nope. int * is a pointer to an integer type, but so it int[]. The [] syntax is simply a shorthand. This is not to say that they are interchangeable -- they're not. But for most purposes in declarations, they are.

 

Well...

1. Comment out everything until the error disappears.
2. Use the same syntax for prototype and actual function.

What OP used here is old K&R style. Normally these days variable names are included.

In C you also can't have different function prototypes. Only one is allowed.

 

No problem with this. What raised a red flag for you?

The { between the = and "

 

The function prototype wasn't the problem -- it was completely consistent with the function declaration. Function prototypes are not required to have parameter identifiers, but of course, function declarations are. I prefer including the variable names in the prototypes because (1) it's an easier and less error prone way to do it -- just copy the prototype to make the declaration, or vice versa, (2) it adds documentation to the prototype, which is particularly useful when and if the prototype is placed in a header file. But, then again, I have adopted the convention of putting main() at the end of the file containing it and to not put any function prototypes in a file for functions contained in that file. That's a big shift from the way I used to do it, which was to put main() at the top and to put prototypes for every function in the file above main() or in that file's header file. There are advangates to both conventions, but I have become convinced that the way I do it now has the stronger merits.


Putting 'size' in the function prototype probably would have generated an error at prototype because, while an identifier name is ignored, a literal constant generally isn't. What I don't know is if a compiler would have been allowed to ignore it and continue on -- but most wouldn't.

 

The { between the = and "

I figured that was likely the case.

Within a string literal, you only have to escape characters that either are not printing (such as the newline, tab, bell, and carriage return) or delimiters that have to be recognized even within a string literal. Usually (I believe) the only two of those are the backslash (which has to be recognized in order to escape anything) and the double quotes (which has to be recognized in order to end the string).

You can have any of the parentheticals, the single-quote, the percent sign, etc.

Many people think that you can't place a percent sign directly into a string literal, but this is based on string literals used as the format strings for members of the printf() family of functions. But this constraint isn't imposed by the language, but by the processing performed by the printf() function. If it were a constraint imposed by the language, it would be escaped with a backslash and not another percent sign.