My C library has some optional features, and using automake, the user can turn them on and off by providing flags to configure.
If a feature is turned off, that function will not be compiled.
However, my question is, should I also remove the function prototype from the public headers in that case?
It seems like not a good idea to have function prototypes for functions that are not compiled, but it also seems to me not a good idea to have different public headers installed depending on the library configuration. (Similar to how it's bad practice to install config.h
in the public headers directory.)
What's the best approach for public headers when it comes to optional features? If a user tries to use a disabled feature, should the error come at compile time, or link time? There must be a standard practise for this situation. (I prefer to comply with GNU coding standards if there are multiple ideas, but I don't know of the GNU standard on this issue.)
stdio. h is a header file which has the necessary information to include the input/output related functions in our program. Example printf, scanf etc. If we want to use printf or scanf function in our program, we should include the stdio.
The header file contains only declarations, and is included by the . c file for the module. Put only structure type declarations, function prototypes, and global variable extern declarations, in the . h file; put the function definitions and global variable definitions and initializations in the .
Including Multiple Header Files: You can use various header files in a program. When a header file is included twice within a program, the compiler processes the contents of that header file twice. This leads to an error in the program. To eliminate this error, conditional preprocessor directives are used.
A header file should be included only when a forward declaration would not do the job. The header file should be so designed that the order of header file inclusion is not important.
Definetely don't only exclude the implementation from the compilation, but the whole function.
//feature.h
#ifndef EXCLUDE_FEATURE
void foo();
#endif
//feature.c
#include "feature.h"
#ifndef EXCLUDE_FEATURE
void foo()
{
}
#endif
This way, you'll get a compiler, not linker error, if you try to use foo
with the feature excluded. You want to signal an error as soon as possible, linker errors in general transmit less about the intention of the developer.
Microsoft does this (conditionals in header files) for MFC and it works quite nicely. (of course that's C++, but the principle stands.
I think there are 2 valid approaches to this problem
#ifdef
to remove functions which aren't supported in certain configurations#ifdef
each of which is specific to a configuration It seems like a really bad practice to leave functions which aren't present in the lib in the header file for a given configuration. It will take what should be a compile time error and move it to a linker one.
I observed the following approach in some projects: Generate the header file from a template one.
The file generation is based on the configuration flags.
This approach seemed to me more clean than using never ending conditionals definitions in the header... to me it seems much more clean.
Disadvantage: It may be a support burden (for the script).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With