Is forward declaration of methods necessary in c?

[megatron]

In the scenario 1 I must declare method on the top, but should I declare it in the scenario 2 also?

Scenario 1:
=========
Static void local_method(int param);

Void caller()
{
local_method(1);
}

Static void local_method(int param)
{
// doing something
} 


Scenario 2:

/* I have define this method before caller, should I still declare its method signature above.
What is the benefit I will get if I declare it  on the top */
Static void local_method(int param)
{
// doing something
} 

Void caller()
{
local_method(1);
}

[mouser]

this is a question that would probably create some real debate among long time c/c++ coders.

let's start with the most important answer:
in scenario 2, you do not have to use a forward declaration; putting one in won't hurt but won't "do" anything for you, technically speaking.

once you accept that, you can get to the more interesting debate about style.

the more modern stylistic approach in c/c++ these days, which i am a big fan of, is to have separate header (.h) files and .c/.cpp files for every source code file (and including the header at the top of the .c/.cpp file).  in your header file you would then get into the habit of having forward declarations for EVERY function.

with this approach, you aren't using forward declarations only when you need them, but out of habit and style, so that you don't have to figure out when you need them and when you don't, and you don't have to worry about order of declaration.

many coders also like having the forward declarations as a kind of summary of the functions declared below (or in the .cpp file if we are using paired header-source code files).

now there are still cases when defining classes where you have to worry about forward declarations, and even worry about the order of declaring classes, but they tend to be few and far between when you get into the habit of always using .h vs .c/.cpp pairs.

[f0dder]

Hm, I'm not a big fan of that approach, mouser.

Imho .c/.cpp files should only have an associated header file if they export functionality that can be used by other source code modules - and only the relevant exported functionality should be listed in the header files. Encapsulation and all that...

When writing your code, group logically related functionality together. If that means having to write function prototypes, so be it. Also, mark non-exported functions as "static" (modern C++ dictates that you should put in an anonymous namespace instead, but I still prefer "static" - has to do with what many compilers end up putting in your .obj files, but that's a long story). But either static or anonymous-namespace should indeed be used to enforce encapsulation, and avoid namespace clashes.

[megatron]

Yes that is a good approach and it is followed almost everywhere (“as far as I know”)...

This is my understanding from your answer:
1. you only meant non-static methods in the .h file. 
2. Static method signature does not required if static method definition is placed before caller method.

But I faced lot of question when I don’t put the declaration of a static method in case 2. I could not find a book or a link which says that this is not necessary (which I can send to a person to justify my point)

[f0dder]

For method #2, there's no reason to write function prototypes (and it's not required for neither C nor C++).

What I meant in my above post was that I wouldn't try rearranging code just to avoid the prototypes, I rather place code "logically" grouped, and write function prototypes if I must.

[megatron]

For method #2, there's no reason to write function prototypes (and it's not required for neither C nor C++).

I got your point… but I have seen people almost “killing” others to prove that method#2 should have a forward declaration…. But I could not find a online link which can explain in depth that there is no need for forward declaration in method#2….