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
// ... #include "config.h" // ... #ifdef HAVE_INT64_T #define AWESOME_FEATURE(x) ((int64_t)(x) + 1) extern int64_t const stupid_value; #endif // ...
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?