Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Jens Schweikhardt <usenet@schweikhardt.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Meta-C question about header order |
| Date | 2014-04-23 19:27 +0000 |
| Message-ID | <brqignFa4lcU1@mid.individual.net> (permalink) |
| References | <bqtj0hF60hpU1@mid.individual.net> <kfnbnvxlo8w.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch <txr@alumni.caltech.edu> wrote
in <kfnbnvxlo8w.fsf@x-alumni2.alumni.caltech.edu>:
# Jens Schweikhardt <usenet@schweikhardt.net> writes:
#
#> consider a small project of 100 C source and 100 header files.
#> The coding rules require that only C files include headers,
#> headers are not allowed to include other headers (not sure if
#> this is 100% the "IWYU - Include What You Use" paradigma).
#>
#> The headers contain only what headers should contain:
#> prototypes, typedefs, declarations, macro definitions.
#>
#> The problem: given a set of headers, determine a sequence of
#> #include directives that avoids syntax errors due to undeclared
#> identifiers. I.e. if "foo.h" declares type foo_t and "bar.h" uses
#> foo_t in a prototype, "bar.h" must be included before "foo.h".
#
# I have been reading the many comments in this thread with some
# interest. Reading through your responses, I have come up with
# this summary of motivations for using this approach (these are
# my paraphrasings, often not quotes of the originals):
#
# + no lint warnings about repeated headers
# + no need for include guards
# + doxygen dependency graph much simpler
# + no cycles in include graph
# + removing unneeded includes is easier
# + simpler compiler diagnostics
# + easier to generate dependency makefile
# + improved identifiability of refactoring opportunities
# + ... and of interface accumulation [not sure what this means]
# + ... and of code collecting fat
# + constant reminders of all dependencies of each .c file
Thanks Tim, for taking the time. To expand on interface accumulation:
the process where interface A needs another, which then grows the need
for yet another and eventually includes half the total number of
interfaces of the project.
Lets face it: programmers are lazy, and its too easy in C to blow up an
initially small interface design by writing another #include in the
first header that looks like it's included by "most" of the files where
it is needed and include it directly where not. How many projects have
you seen with project_types.h, misc.h, macros.h, and such headers
invented on the spot.
# Some questions:
#
# 1. Is this an accurate summary?
#
# 2. Has anything been left out (ie, is there any other
# positive you would add to the list)?
+ Reduced processing time by all the tools that operate on
C source. That's the compiler of course, but also lint,
auto dependency generators, static checkers, doxygen, ...
For each translation unit, the headers are tokenized and
parsed at most once (not at all when in an disabled #ifdef).
I observe 20% in our project.
+ Giving developers a hard and fast unambiguous rule in which file the
include directives go. There is only one choice. If foo.c needs the
bar_t declaration from bar.h, it gets included. Contrast this with
"traditional wisdom", where possibly a large number of headers would be
candidates for the new #include statement. A good design would make this
choice obvious, a bright developer would know the state of the art, but
it's a rare trait. "Indented six feet down and covered with dirt" is the
reality out there. Yes, this requires selection of the proper *line*
among the includes. But *any* compiler will tell in no uncertain words
if that was the wrong line or you're missing another header. It's fool
proof.
# 3. Would you mind listing these from most important
# to least important, and giving some indication of
# relative weight for each item?
+ improved identifiability of refactoring opportunities
$ grep -c '#include "foo.h"' */*.c
Whoa! foo.h is included by 95% of files, why?
Whoa! foo.h is included by one file only. Maybe incorporate it.
Hmm. All foo.h require bar.h, baz.h and blurb.h. Could I
encapsulate this better? Maybe merge some headers?
(50 points)
+ ... and of interface accumulation
$ grep -c '#include' */*.c
Whoa! big.c includes everything and the kitchen sink. What's up?
(30 points)
+ ... and of code collecting fat - optional debug code in #ifdef maze.
Should be moved out to separate object files, linked in when needed.
(20 points)
+ doxygen dependency graph much simpler. It's a document for
the customer.
(20 points)
+ removing unneeded includes is easier
(20 points)
+ constant reminders of all dependencies of each .c file
(10 points)
+ no cycles in include graph
(10 points)
+ giving developers a fast rule in what file the include goes.
(10 points)
+ reduced processing time by all the tools that operate on source
(10 points)
+ no lint warnings about repeated headers
(10 points)
+ easier to generate dependency makefile
(7 points)
+ no need for include guards
(5 points)
+ simpler compiler diagnostics
(5 points)
The overall goal is to make emerging complexity stand out the moment it
emerges, opening developers eyes. The reality in any random project is:
not all developers are stellar C programmers (the set of participants in
this newsgroup then and now looks like an accurate statistical sample.
From Tanmoy to Bill...)
Unfortunately, the C preprocessor is a deceptive tool (apologies to dmr,
may his soul rest in peace, I know why it was needed in the time back
then) and gets frequently abused. Taming it is probably what I'm after.
The only reason cpp has survived is because of the include guard kluge.
Making interfaces stand out, both in number and circumference, should
help, I hope.
[...]
#> Can you think of a lightweight way to solve this? Maybe using
#> perl, the unix tool box, make, gmake, gcc, a C lexer?
#
# I may have some suggestions here, but first I would like to read
# through responses to the questions asked above, to make sure I'm
# going in a good direction.
This is certainly incomplete:
One would need to find the identifiers of macro definitions (easy)
and typedefs (harder). In prototypes one must distinguish between
types and optional parameter names.
In other declarations one needs to determine the declared identifier.
This is a little more involved for enums and aggregates.
Build the "needed by" pairs and pipe to tsort(1). Voilà!
Version 7 came with all the goodies built in, didn't it?
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-12 19:37 +0000
Re: Meta-C question about header order Keith Thompson <kst-u@mib.org> - 2014-04-12 13:51 -0700
Re: Meta-C question about header order glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-13 00:11 +0000
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 11:40 +0000
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-13 13:10 +0100
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-13 06:29 -0700
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 14:41 +0000
Re: Meta-C question about header order Ken Brody <kenbrody@spamcop.net> - 2014-04-15 10:36 -0400
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-12 16:58 -0400
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 03:40 +0000
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-13 16:26 +1200
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 05:02 +0000
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-13 17:21 +1200
Re: Meta-C question about header order Ken Brody <kenbrody@spamcop.net> - 2014-04-15 10:59 -0400
Re: Meta-C question about header order Ken Brody <kenbrody@spamcop.net> - 2014-04-15 11:02 -0400
Re: Meta-C question about header order Ken Brody <kenbrody@spamcop.net> - 2014-04-15 10:59 -0400
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-15 08:26 -0700
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-15 15:56 +0000
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 11:34 +0000
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-13 15:04 -0400
Re: Meta-C question about header order Ken Brody <kenbrody@spamcop.net> - 2014-04-15 10:52 -0400
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-13 11:09 +1200
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 11:47 +0000
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-14 08:54 +1200
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 21:37 +0000
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-14 09:49 +1200
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-14 19:17 +0000
Re: Meta-C question about header order Ian Collins <ian-news@hotmail.com> - 2014-04-15 10:24 +1200
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-16 19:58 +0000
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-14 21:45 -0400
Re: Meta-C question about header order luser- -droog <luser.droog@gmail.com> - 2014-04-12 16:48 -0700
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 11:52 +0000
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 01:04 +0000
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-13 10:15 +0100
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-13 04:06 -0700
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 12:01 +0000
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-13 13:46 +0100
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 13:58 +0000
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 11:29 +0000
Re: Meta-C question about header order Martin Shobe <martin.shobe@yahoo.com> - 2014-04-13 08:48 -0500
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-13 14:25 +0000
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-13 15:02 +0000
Re: Meta-C question about header order Martin Shobe <martin.shobe@yahoo.com> - 2014-04-13 21:45 -0500
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-14 01:16 -0700
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-14 10:16 +0100
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-14 21:33 -0400
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-14 16:25 +0000
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-14 09:47 -0700
Re: Meta-C question about header order Martin Shobe <martin.shobe@yahoo.com> - 2014-04-14 13:29 -0500
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-14 19:31 +0000
Re: Meta-C question about header order Les Cargill <lcargill99@comcast.com> - 2014-04-14 20:03 -0500
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-15 01:04 +0000
Re: Meta-C question about header order Keith Thompson <kst-u@mib.org> - 2014-04-14 15:15 -0700
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-14 22:01 -0400
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-15 09:51 +0100
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-15 06:01 -0700
Re: Meta-C question about header order "BartC" <bc@freeuk.com> - 2014-04-15 14:29 +0100
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-15 10:38 -0700
Re: Meta-C question about header order Kaz Kylheku <kaz@kylheku.com> - 2014-04-15 18:27 +0000
Re: Meta-C question about header order Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-15 12:45 -0700
Re: Meta-C question about header order ralph <nt_consulting@yahoo.com> - 2014-04-15 22:02 -0500
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-14 17:44 +0000
Re: Meta-C question about header order Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-19 01:25 -0700
Re: Meta-C question about header order Richard Damon <Richard@Damon-Family.org> - 2014-04-19 10:30 -0400
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-23 19:47 +0000
Re: Meta-C question about header order James Kuyper <jameskuyper@verizon.net> - 2014-04-23 15:53 -0400
Re: Meta-C question about header order Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-10 09:25 -0700
Re: Meta-C question about header order Jens Schweikhardt <usenet@schweikhardt.net> - 2014-04-23 19:27 +0000
Re: Meta-C question about header order Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-10 09:40 -0700
csiph-web