Configuration related defines in public header?

Question

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 breaks

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

Answer 1

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.