scs@adam.pika.mit.edu (Steve Summit) (08/17/89)
Last night I posted a long article exploring the impossibility
of writing a standalone stdio.h, that is, one that does not not
somehow "know" the underlying type of a va_list without
#including <stdarg.h>. Doug Gwyn is about to post an article
saying that allowing standalone reimplementation of parts of the
C run-time library was never an X3J11 requirement, and I'm sure
that's true, but I don't have to like it. In fact, there is a
way out of this particular dilemma, although it's too late now.
The essential problem is the requirement that <stdio.h> contain
prototypes for vprintf, vfprintf, and vsprintf. The v*printf
family are "crossover functions:" they combine functionality from
the stdio and stdarg (nee varargs) subportions of the library.
In languages with more formal type and class concepts, explicit
means are often required to implement such crossover functions,
such as the "friend" function notation of C++.
A solution would have been to acknowledge the special nature of
the v*printf by putting them in their own header file, vprintf.h:
#include <stdio.h>
#include <stdarg.h>
extern int vprintf(char *, va_list);
extern int vfprintf(FILE *, char *, va_list);
extern int vsprintf(char *, char *, va_list);
In general, I'd have preferred it if X3J11 had been somewhat more
granular in their assignment of new header files. As another
example, it would be convenient if malloc, realloc, and free were
in a <malloc.h> rather than lumped in with everything else in
<stdlib.h>. (This could make it easier for implementors of
debugging versions of malloc, intended to replace or sit atop
the vendor-supplied one.)
I realize that picking the right header file granularity involves
tradeoffs. There are probably programmers who dislike having to
#include everything under the sun and would prefer an opposite
extreme, something along the lines of <libc.h> or <everything.h>.
Many of my source files start out with 15 or 20 #include
directives, and while this may not be ideal, I much prefer the
flexibility that finer granularity affords.
Steve Summit
scs@adam.pika.mit.edudiamond@csl.sony.co.jp (Norman Diamond) (08/22/89)
In article <13574@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >I realize that picking the right header file granularity involves >tradeoffs. There are probably programmers who dislike having to >#include everything under the sun and would prefer an opposite >extreme, something along the lines of <libc.h> or <everything.h>. >Many of my source files start out with 15 or 20 #include >directives, and while this may not be ideal, I much prefer the >flexibility that finer granularity affords. As a quality-of-implementation issue, both needs could be met. <stdlib.h> can just be a list of nested #include's of standard (well, not really standard, but what else do you call them) include files with a finer grain. (At least namespace pollution is not a problem in naming standard include files.) -- -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.