Alex Rivera | Logout

is it considered good practice to have conditionals in public header files?

Asked 2012-03-09T18:34:02.093
10

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.)

c shared-libraries gnu automake
Edit
Report

1 Answer

1

I think there are 2 valid approaches to this problem

  • Have a single header file which uses #ifdef to remove functions which aren't supported in certain configurations
  • Have multiple header files with no #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.

answered 2012-03-09T18:41:12.657

Your Answer