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;#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 breaksThus: Is it considered bad practice to put configuration #defines into public library headers? And if so, what are the alternatives?
Configuration related defines in public header?
c++;c;api design;configuration;headers