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