Suppose you're building some library, C or C++ doesn't really matter for this question, IMO. The features (or implementation thereof) depend on capabilities of the target system.

A simple, probably contrived example: Some feature depends on whether the system has a working int64_t (64 bit integer type) or not.

Assuming a GNU style ./configure, one would end up with a config.h with content like:

// ...
#define HAVE_INT64_T 1
// ...

One could then include this config.h (probably with a better name) in the public library header library.h, and let the feature(s) depend on HAVE_INT64_T:

// ...
#include "config.h"
// ...
#ifdef HAVE_INT64_T
#define AWESOME_FEATURE(x) ((int64_t)(x) + 1)
extern int64_t const stupid_value;
// ...

Now, if you're building an application against this library, and your requirements to #define HAVE_INT64_T 1 are different, e.g. more strict than those of the library, you get into trouble when you do:

// ...
#include "app-config.h" // does NOT define HAVE_INT64_T
#include <library.h> // defines HAVE_INT64_T
// -> stuff breaks

Thus: Is it considered bad practice to put "configuration" #defines into public library headers? And if so, what are the alternatives?

  • 1
    It's indeed discouraged to #include <config.h> in header files. Does this answer address what you're asking?
    – 5gon12eder
    May 18 '16 at 20:53
  • @5gon12eder Indeed, using ax_prefix_config_h would solve this perfectly. Regarding this question: Can one close duplicate across site boundaries? May 18 '16 at 21:01
  • I'm glad you found it useful. I'm not aware of any procedure to link an answer on a different site to this question beyond mentioning it in a comment. The only possibility I see is migrating this question to SO which would be unfortunate, as it is perfectly on-topic here. I would also feel stupid copying or paraphrasing my answer or posting a link-mostly answer. So unless a moderator steps in and advises to do something different, I think I'll leave it at that.
    – 5gon12eder
    May 19 '16 at 19:22

It's certainly not a bad practice to keep the library configuration elements grouped in a common configuration header. On the contrary ! It eases portability to other environments/architectures and facilitates maintenance/deployment. And the application configuration could be different from the library configuration.

The only issue is to avoid name collision between your application and library components. In fact, this problem is similar to the naming of include guards: you should not use identifiers which might be used inadvertently for other purpose in other context. The name should be long enough and make the scope of the identifier explicit (e.g. use a naming convention with the library defines starting with the library name).

In some cases (by far not all, unfortunately) you could use language features (e.g. constant definitions, type definitions, templates such as std::enable_if) and benefit from the optimizer (e.g.dead code elimination by the optimizer) to achieve the same results rather than using preprocessor directives. In this case you could easily avoid collision using C++ namespaces. But this is not always feasible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.