[Courses] C Programming For Absolute Beginners, Lesson 5: All About Functions, part 1

[Christopher Howard]

On 03/12/2012 08:28 PM, Carla Schroder wrote:
> 
> Perhaps some our ace gurus could discuss the best places to put your function 
> prototypes. This is not a big deal in our tiny example programs, but in large 
> complex programs what are some best practices?
> 

Not sure if I qualify as an "ace guru", but nonetheless: the most
important thing to understand about function prototypes is that they
allow you to use a function before it has been defined, i.e., before the
compiler knows fully what it does. This will occur if either:

1. You define a function in the file /after/ it is used.

2. You define the function in a separate file.

3. The function is defined in a separate library (for example, a shared
library on your system).

A prototype is like a place holder that tells the compiler, "I'm not
going to tell you what this function does yet; however, I'll tell you
what kind of value it returns, and its parameters, and the size of it's
parameters, and then later on I'll tell you where to find the real
function." In other words, you are giving the compiler just enough
information to work with the function until it sees the real thing.

So, if several files use function "foo()", then typically the prototype
will be stored in a header file. All the files that use foo() will need
to #include that header file, which gives each file a copy of the
prototype. This way each file knows how to work with foo(), without
actually including the full function definition in each file (which
would waste a lot of space). If you wanted to, you could put the
prototype directly in each file (instead of using headers) though it
would be a lot more work:

code:
----------
// file main.c

int myadd (int, int);

int main ()
{
  return myadd (3, 2);
}

// file add.c
int myadd (int a, int b)
{
  return a + b;
}

// You would then compile and link the two files together with this command:

gcc main.c add.c -o myprogname
----------

Though, as I said, it is usually more sensible to put the prototype in a
separate file and #include it among the various files that need it. With
shared libraries (utilizing dynamic linking), you also #include a
prototype from a header, but the real function is not provided at all
during compiling! Rather, it is provided later by the system at the
beginning of the program's execution. This allows people to code their
programs for a particular library interface (i.e., set of function
prototypes) while the library functions themselves may differ somewhat
from system to system. (For example, depending on the special needs of
the system. This is how OpenGL still works, even though we all have
different graphics cards.)

Also note that prototypes are purely for the benefit of the C compiler
(and you, of course). That is, on the assembly level, there are no
prototypes. In assembly language (which is what C compiles into) if you
make reference to function without defining it, the assembler will just
keep on assembling away merrily, assuming that eventually you will
provide a definition for it.

The prototypes are for the benefit of the C language compiler, because C
has a type system and wants to know exactly what kind of data you are
passing into and out of the function, and the sizes of each of those data.

-- 
frigidcode.com
indicium.us