Managing C/C++ Libraries: Dependencies
John Myers
jgm at k.gp.cs.cmu.edu
Thu Nov 17 04:03:42 AEST 1988
In article <3414 at geaclib.UUCP> geaclib!lethe!dave writes:
>From article <8387 at nlm-mcs.arpa>, by mjr at vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum):
>> I wonder how much code would break is such an extension were added,
>> and the #include_once were made the DEFAULT rather than the exception ?
>
> Ok, people! Would this change, made silently, injure correct
>programs? It is admitted that it may allow incorrect programs to
>compile, but that isn't waht I'm concerned about.
Most certainly. There is a programming method used by the GNU C compiler
and other programs which is to create a file of definitions (expressed
as macro invocations) which gets included more than once. For
example, in GCC the file tree.def contains lines like:
DEFTREECODE (ERROR_MARK, "error_mark", "x", 0)
DEFTREECODE (IDENTIFIER_NODE, "identifier_node", "x", 6)
DEFTREECODE (TREE_LIST, "tree_list", "x", 2)
One then defines the macro DEFTREECODE to do whatever one wants and
then #include's tree.def. For example, in tree.c:
#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
char *tree_code_type[] = {
#include "tree.def"
};
#undef DEFTREECODE
#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
int tree_code_length[] = {
#include "tree.def"
};
#undef DEFTREECODE
I also have a header file that generates a function to do a bitblt for
a given binary operation. One #define's a macro to specify the binary
operation and then #include's the file. This is usually repeated for
each of the binary operations.
--
_.John G. Myers Internet: John.Myers at cs.cmu.edu
LoseNet: ...!seismo!inhp4!wiscvm.wisc.edu!give!up
"The world is full of bozos. Some of them even have PhD's in Computer Science"
--
More information about the Comp.lang.c
mailing list