Function prototype - what they are and why you should use them - C and C++
Archive - Originally posted on "The Horse's Mouth" - 2015-10-27 08:31:50 - Graham EllisIn C and C++, your program if it's anything but trivial will be written in multiple source files. Each will be compiled into a snippet of runnable code - an "object" file - before all of these object files are linked / loaded together, and with standard libraries, using a program known by various names over the years such as "task builder" and more obviously "loader". You may think of the output from the loader as a complete program, though these days shared libraries may be dynamically loaded at runtime in order to avoid the repetition is large numbers of programs of the same code for things like outputting text.
Your multiple source files are connected at load time via calls in your main and higher level program code to methods or functions in the code that's at a lower level, and it's useful at compile time (when you're working on individual code sections) to know that you have the calls right - that you've written the correct names for the functions, and that the number and type of parameters you've used is going to be what's expected by the code you're calling in another file. And to get this right, you use function prototypes - declarations of valid function calls for the compiler to check against at compile time rather than later on.
Function prototypes are like function definitions without the block of code or variable names - for example:
int spaces(int *,int);
defines a function that is called with an integer pointer (an array, perhaps) and a second integer, and returns an integer. To make it more readable, names could be given to the parameters:
int spaces(int *values,int counter);
but those extra words are really just comments.
In order to share your function prototypes between many source files that may call them, function prototypes are often written into header files (.h is the convention) and read into each source file that may call the fuctions by the C preprocessor using the #include directive. That way, you've just got one file of headers to maintain.
Although function prototypes feel unnecessary, they save you a huge amount of heartache later in the compile - or even run time - with your program. Better to have a bit of early codeing expense that to find a problem later on when you come to load, or worse to find the problem at runtime. For if you get the call sequence wrong, you can end up with some program bugs that are really hard to find. Even experienced coders dread "Bus Error", "Segmentation Fault" or "Segmentation Violation".
These error messages all really mean that your program has tried to access data that's outside your addressing space - whether it's trying to access the system bus, memory space that's not yours or memory that doesn't exist will effect which message you happen to get. There are many causes - but the most common one you'll experience without function prototypes is damaged function calls where the pieced of the jigsaw haven't fitted properly together. And the error tends not to be flagged at the point of error - but later on when the error causes further problems. Moral - use function prototypes, even if they feel like they're a pain!