headers including headers (was: Re: svn commit: rev 1181 - trunk/subversion/bindings/ruby)

On Mon, Feb 04, 2002 at 09:48:20PM -0500, Garrett Rooney wrote:
>...
> all these files #include "util.h", which has the following prototype
> in it:
>
> svn_client_revision_t svn_ruby_parse_revision (VALUE revOrDate)
>
> only client.c and log.c actually use it though, so perhaps the
> function should be moved out of util.{c, h} to someplace more 'client
> level'. or we could have util.h #include <svn_client.h>, but i've
> always been told that headers that #include other headers is a bad
> thing.

Headers _can_ and they _should_ include other headers. If a header has a
typedef that is located in another header, then it must include it. Each
header must be compilable on its own.

If header FOO does not include a dependent header (to get a typedef; call it
BAR), then all users of FOO must somehow know to include BAR first. That is
just wrong, and introduces all kinds of "gotchas" into the system.

What *is* bad, is a header that "includes the world." A given header should
include dependent headers for its types, and nothing more. When somebody
includes FOO, they should "only" get FOO. (of course, they will also get BAR
because that was included, but we can minimize the "extra" stuff that gets
pulled in)

To some extent, when a .c file includes headers, it is self-documenting. If
the .c file is including, it is using it. The "world" headers hide what
kinds of things a .c file might be using. (this generally applies to .h
files, too -- what stuff does a .h file need?)

In the past, I've written little shell scripts to attempt to compile each
header. Then I go in and trim out the headers which aren't truly needed.
(of course, you can sometime accidentally remove a header which is needed,
but it happens to be included via another header, but you just need to be a
bit observant to try and avoid that)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org