Mail Archives: djgpp/2004/04/01/06:16:39
Andris Pavenis <pavenis AT latnet DOT lv> wrote:
> It's in DZCOMM documentation (it was not read carefully enough):
> -------------------- fragment from documentation ----------
[...]
> include the allegro library. If you do so it is IMPERATIVE that you
> include allegro first (this how dzcomm knows where to link to):
> #include <allegro.h>
> #include <dzcomm.h>
This violates a number of sanity rules for #include file design. As
in: it should always be irrelevant in which order you #include files,
and it should make no difference how often you #include each of them.
If DzComm needs special tricks to cohabitate with Allegro, fine, let
the user
#define DZCOMM_USED_WITH_ALLEGRO 1
or whatever. Relying on #include file ordering is way too fragile to
be a good solution.
> If you have more than one C file in a project and you wish to
> access dzcomm from more than one of those files, you must put the
> following #define before all but one of the dzcomm includes:
> #define DZCOMM_SECONDARY_INCLUDE
> #include <dzcomm.h>
This is worse yet. I consider an #include file that requires such
artistics to be used as pathecally ill-designed. This file should
_always_ behave as if this #define had been set.
Whatever it exposes without that macro defined doesn't belong in a
public header file in the first place. Such stuff belongs into one of
the .o files that form the actual library, not in the header. If
at all, the #define should work the other way round, i.e. make it
#define DZCOMM_EXPOSE_DEFINITIONS 1
#include <dzcomm.h>
once, and plain
#include <dzcomm.h>
in all other cases.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -