[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dev-serveez] libserveez.h #includes
From: |
Julian Graham |
Subject: |
Re: [dev-serveez] libserveez.h #includes |
Date: |
Tue, 13 Nov 2012 00:31:08 -0500 |
Hey ttn,
> Stuff like #include <stdio.h> were never in libserveez.h, so for now i'm
> inclined to leave them out, due to inertia and lack of gumption mostly.
Well, actually, it was -- transitively. Before libserveez.h started
getting generated at build time (which started at eb9d7c), it just
aggregated other header files, including libserveez/util.h, which
contains some of the functions that gcc was complaining about.
libserveez/util.h doesn't currently include stdio.h, but it used to up
until 5fcb62 when it was moved to libserveez/defines.h. (It was
deleted from libserveez/defines.h in 0a95a8.)
So I think that's why building against libserveez.h used to work for me?
> Some things are straightforward (AFAICT), like #include <stdio.h>.
Really? My .c file that was using libserveez.h didn't need anything
from stdio.h -- and still doesn't, since it's not using any of those
functions that takes a FILE pointer -- so I had to dig around in
libserveez.h to see why things were broken. This seems like a bit of a
violation of encapsulation to me.
I saw some commit comments to the effect that header files should
never #Include <stdio.h>. Is that a general bit of C convention with
which I'm unfamiliar? I'm actually curious, and a Google search
reveals a fair number of differing opinions on how to organize header
file dependencies. My M.O. to date has been: If a .c or .h file itself
refers to a type or function that it does not itself define, then it
should #include the header that's "responsible" for defining that
type, even if that header is already transitively #Included.
> Perhaps it would be reasonably helpful to list in the manual all the
> system headers used (or rather, mentioned) in the code base and say that
> configuration (to determine the preprocessor conditionals) is the client
> code's ball of wax, standard disclaimers apply, do not taunt happy fun
> libserveez.h, etc...
I suppose if it were documented I could live with it. It still forces
me to #include libserveez.h with a particular ordering relative to
stdio.h (i.e., stdio.h and friends must come before libserveez.h),
which is a little annoying.
Thanks,
Julian