Question

Some C code for common tasks may be shared among projects and kept for future use. But how should I keep them? In .c or .h? I notice that C header files (.h) generally contains only function declarations, not definitions, and this seems to be the recommended practice.

  1. Put declarations and definitions in mycode.h, so I can simplely #include "myheader." and leave all jobs to the compiler.

  2. Put declaration in mycode.h and definitions in mycode.c. Probably conforming the convention? But I have to compile and link mycode.c each time.

What is the best practice? Any suggestions?

EDIT:

Everyone says #2 is the better practice. But how can I tell the compiler where the definition/implementation(.c/.o/.so?) reside in a header file? As I simply #include and use printf(...);?

No correct solution

OTHER TIPS

Make a library (.so or .dll - your poison) then link to it

The header file will then tell the compiler what is available to it

Option 2 is the best practice. Why is option 1 bad? If definitions exist in headers, those definitions have global scope. It strips away modularity of the software. Restricting the scope of variables is good practice as the software units are less coupled and therefore the software is easier to maintain.

Only the .c files that have changed need be compiled if a make system is used.

It really depends on the number of files to be shared between your projects.

  • if you got a big interconnected collection of files it is usually best to create a dynamic library or static library and link your application(s) statically or dynamically against that.

  • In general - stick to #2

The best practice is the second option, because it's not only simplicity but also about enhancement and maintaince

Although not frequently used, I have seen projects that included lots of code in a .h. If you are positively sure that the code will only be used in one project only, I don't think that there is a major drawback in placing the code in the header, although it is quite unusual.

I would advise to place it in a .c though in order to be able to compile it as a separate module or shared library. This will ease the work of other developers and allow for a greater reusability.

The header file is the window to the outer world, this is, what the code does (the interface). The how it does (details of implementation) is something that other modules and projects really don't care.

Suppose you own a grocery, and your client asks you for a dozen of apples. You: -Check if there are apples in the display. -If not, go to the back room to get some. -If you ran out of apples, tell the client about it, and place an order to restore stock.

However, your client just wants his dozen of apples; does not care so much about the details of his order.


You may see cases in which the declaration and definition lay at the same .h file. When working with c++ templates this is mandatory as far as I am concerned. In the rest of the cases, it supposes extra build time, as those definitions will be compiled despite not having changed since the last build.

Use Second Option ... Or Create the library whether it is dynamic (.so) or static (.a) it depends on you .. Yes, Dynamic Libraries Size is less compared to static Libraries. So Second Option is best.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top