Making function private/ not supplying declaration in header file

[Daniel Nichols]

I've noticed that in a C module (.c, .h file combination) that if you
create a function's definition before it is used in other functions
than a declaration is not necessary. I believe if the compiler can
find the definition of the function prior to encountering the use of
the function it will generate the prototype itself.

I don't currently use this feature, I explicitly create declarations
for all functions in a header file. However, I do think this feature
would be jolly useful for functions which can be thought of as private
to the module and nobody else ever needs to use. As well as not
actually appearing in the header file, so nobody will try to use it,
if the signature for this function is changed no changes are necessary
to the header file and we therefore remove a whole set of dependencies
when we re-compile.

Is the consensus that this is a good compiler side-effect to use or is
it best avoided, to become de-supported, already not supported by C++,
etc.

Thanks,
Daniel.

 

[Eric Sosman]

I've noticed that in a C module (.c, .h file combination) that if you
create a function's definition before it is used in other functions
than a declaration is not necessary. I believe if the compiler can
find the definition of the function prior to encountering the use of
the function it will generate the prototype itself.

Your terminology is inexact, but you've got the right idea.
For future reference, the "prototype" is the description of the
argument list. "ANSI-style" functions have prototypes, "K&R"
functions do not. What you've observed is not about prototypes
at all, but about declarations: A definition (of a function or
a variable) also serves as a declaration. If the compiler has
seen the definition of your function, it has _ipso facto_ seen
a declaration of it.

I don't currently use this feature, I explicitly create declarations
for all functions in a header file. However, I do think this feature
would be jolly useful for functions which can be thought of as private
to the module and nobody else ever needs to use. As well as not
actually appearing in the header file, so nobody will try to use it,
if the signature for this function is changed no changes are necessary
to the header file and we therefore remove a whole set of dependencies
when we re-compile.

It is good practice (and required under C99 rules) to declare
a function before using it, but it is not necessary to do so in
a header file. Use headers for declarations you wish to "export"
to other modules, but don't use them for "private" functions or
variables. (Also, use the `static' keyword on your "private"
functions and your "private" file-scope variables.)

Is the consensus that this is a good compiler side-effect to use or is
it best avoided, to become de-supported, already not supported by C++,
etc.

There is nothing wrong with letting a definition serve as
the only declaration of a function or variable. The practice
tends to lead to a "Pascal style" of coding, with all the little
low-level functions at the beginning of the file and main()
clear down at the bottom, and some people find this irksome to
read. (Others find it irksome to write both a declaration and
a definition; why repeat twice the same information twice?) You
pays your money and you takes your choice.

 

[Default User]

I've noticed that in a C module (.c, .h file combination)

The correct term for this (after all preprocessing in complete) is
"translation unit".

that if you
create a function's definition before it is used in other functions
than a declaration is not necessary. I believe if the compiler can
find the definition of the function prior to encountering the use of
the function it will generate the prototype itself.

No. A prototype is a declaration of a function that declares the types
of the function parameters. So when you define a function with a
prototype declaration ahead of any use, you HAVE prototyped the
function.

I don't currently use this feature, I explicitly create declarations
for all functions in a header file. However, I do think this feature
would be jolly useful for functions which can be thought of as private
to the module and nobody else ever needs to use.

That is used sometimes for static (local to the translation unit)
functions.

Is the consensus that this is a good compiler side-effect to use or is
it best avoided, to become de-supported, already not supported by C++,
etc.

I don't know what you mean by "compiler side-effect". That a different
use of the term side effect than I've ever seen.

It's the same in C++. No, it's not going away.


Brian Rodenborn

 

[CBFalconer]

.... snip ...

I don't currently use this feature, I explicitly create declarations
for all functions in a header file. However, I do think this feature
would be jolly useful for functions which can be thought of as
private to the module and nobody else ever needs to use. As well as
not actually appearing in the header file, so nobody will try to use
it, if the signature for this function is changed no changes are
necessary to the header file and we therefore remove a whole set of
dependencies when we re-compile.

It is used all the time. Simply mark the private functions as
static. e.g.:

static int foo(int bar)
{
/* whatever */
}

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

I've noticed that in a C module (.c, .h file combination) that if you
create a function's definition before it is used in other functions
than a declaration is not necessary. I believe if the compiler can
find the definition of the function prior to encountering the use of
the function it will generate the prototype itself.

I don't currently use this feature, I explicitly create declarations
for all functions in a header file. However, I do think this feature
would be jolly useful for functions which can be thought of as private
to the module and nobody else ever needs to use. As well as not
actually appearing in the header file, so nobody will try to use it,
if the signature for this function is changed no changes are necessary
to the header file and we therefore remove a whole set of dependencies
when we re-compile.

To guard against misuse of these, make the functions static, and don't put
them in header files.

Is the consensus that this is a good compiler side-effect to use or is
it best avoided, to become de-supported, already not supported by C++,
etc.

It is imho good practice not putting functions that are not supposed to be
used outside a compilation unit (.c file) in a header file. One doesn't
need to expose more to other units than needed You can declare them at the
top of the .c file instead. Such "private" functions can often be made
static as well.(and some compilers can take advantage of that, increasing
speed).

 

[kal]

It is used all the time. Simply mark the private functions as
static. e.g.:

static int foo(int bar)
{
/* whatever */
}

Ah, yes. Thank you. I was starting to wonder if anyone is
going to mention the "static" declarator. After all, merely
omitting the declaration maketh not a function private.