OSDev.org

Hello.

I am making an OS and I want to know do I have to keep track of all the functions in one header file to avoid "implict declaration"s when called.
Is there an easier way?
It doesn't seem to work if I put a func-declaration right above the func-code, but it works if I put the delcarations into a header file (, above all the function codes).

A function declaration must be placed above the first use of the function, not above the definition of that function.

It is "traditional" to put related functions into one .c file, and declaring all functions of that .c file in a corresponding .h file. Put that header in a "header" guard to protect against multiple inclusion:
...and include the header in any other file that uses code from the .c file.

That's how it's done in 99.9% of all cases, and trust me, it doesn't get any simpler than that in the long run.

OSMAN wrote: Hello.

I am making an OS and I want to know do I have to keep track of all the functions in one header file to avoid "implict declaration"s when called.
Is there an easier way?

You usually want to have a header for each group of related classes, structures, functions, and global variables. This allows you to include the headers for the specific modules you need, while restricting their visibility to only those modules, which helps avoid namespace clashes.

It is very useful to think of the code in terms of modules - groups of related structures and functions - rather than individual functions. This allows you to abstract away the module, and design the program as whole rather than getting bogged down in the details. Conversely, proper modular decomposition allows you to work on only the part of the program you are working on at the moment without having to worry about conflicting with some other, unrelated part.

This is one of the main reasons that OOP is so useful (when used appropriately): it gives a universal constructor for modules (the class, which combines the data structures and the functions into a single construct) and an overarching metaphor (simulation of physical objects) which turns the separate elements into a single unified concept. While it is not a perfect paradigm by any means - no one methodology is universal, except procedural programming, which is equally mediocre for all purposes - it is a very powerful part of one's programming toolkit.