Xref: utzoo comp.lang.c:21048 comp.std.c:1552 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond From: diamond@csl.sony.co.jp (Norman Diamond) Newsgroups: comp.lang.c,comp.std.c Subject: Re: va_list used in Keywords: va_list, X3J11, vfprintf, header files Message-ID: <10722@riks.csl.sony.co.jp> Date: 22 Aug 89 10:43:23 GMT References: <1140@midgard.Midgard.MN.ORG> <10720@smoke.BRL.MIL> <2095@dataio.Data-IO.COM> <10739@smoke.BRL.MIL> <13572@bloom-beacon.MIT.EDU> <13574@bloom-beacon.MIT.EDU> Reply-To: diamond@riks. (Norman Diamond) Followup-To: comp.lang.c Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan Lines: 22 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 or . >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. 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.