[9fans] Include guards and multiple includes

[9fans] Include guards and multiple includes

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to convince some non-believers that include files should  
not include other include files, and that instead they should state  
their dependencies; they want hard data before they commit to such a  
scheme.

Is there some study kicking around that I could point them at rather  
than re-factor our code base and time the resulting builds?  I know  
the plan9 headers largely follow this pattern.

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFORlRpJeHo/Fbu1wRAlExAKCsTZtCcW9FlqvUwllBye9EgRGqGwCgnYZn
0QcMNw3eC6a/3/XINvcD/Qw=
=H755
-----END PGP SIGNATURE-----

Re: [9fans] Include guards and multiple includes

[Joel Salomon]

> Is there some study kicking around that I could point them at rather
> than re-factor our code base and time the resulting builds?  I know
> the plan9 headers largely follow this pattern.

I'm fairly certain it's a stylistic/maintainability issue on Plan 9,
not an efficiency one.

--Joel

Re: [9fans] Include guards and multiple includes

[Russ Cox]

There was a time when there was an efficiency argument
to be made (don't have to read and parse the files over and over),
but gcc did an end run around it by recognizing files with
the traditional #ifndef #define #endif sequence and
then not even re-opening the file the next time it gets
included.

Arguably gcc didn't even have to do this, though: the rest
of the compiler is so slow that parsing the headers multiple
times is hardly the performance bottleneck.

Russ

Re: [9fans] Include guards and multiple includes

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah well, there goes one argument for keeping the header soup clean.

The best runner-up wrangling technique proposed is that any foo.c  
implementation of the interface in foo.h should have foo.h first to  
ensure that all of foo.h's include requirements are satisfied by  
foo.h itself.   I just wish there were tools for enforcing these  
sorts of things :-(

Thanks,
     Paul

On 20-Oct-06, at 1:18 PM, Russ Cox wrote:

> There was a time when there was an efficiency argument
> to be made (don't have to read and parse the files over and over),
> but gcc did an end run around it by recognizing files with
> the traditional #ifndef #define #endif sequence and
> then not even re-opening the file the next time it gets
> included.
>
> Arguably gcc didn't even have to do this, though: the rest
> of the compiler is so slow that parsing the headers multiple
> times is hardly the performance bottleneck.
>
> Russ

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFOTOnpJeHo/Fbu1wRAgL3AKCK8w/FW9CXIOO1zAtrAisbzJRsrACdHEAJ
Pk+Uj196otCysy4+xmgJcPA=
=TLlz
-----END PGP SIGNATURE-----

Re: [9fans] Include guards and multiple includes

[geoff]

I think that one of the best arguments for organising header files as
Plan 9 does is the mess that /usr/include has become on (l)unix.  It's
almost 20MB on Suse 9.1.

Here's an interesting exercise for people who don't see a problem with
how (l)unix organises /usr/include:

Ask someone (ideally a manager, the higher the rank, the better) to
find out where under /usr/include on Linux the type time_t is defined
and the signal SIGINT is declared without using grep or any
equivalent; they should trace through the include files visually.  If
they return with the correct answers and aren't disgusted with the
mess under /usr/include, slap some pointy hair on them.

Re: [9fans] Include guards and multiple includes

[Bruce Ellis]

an appropriate answer is unfortunately "it doesn't matter,
it'll probably change next week anyway".  the linux kernel
is more fascinating.  ask "is this bit of code ever executed"
or "where is this function called/defined".

brucee

On 10/21/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> I think that one of the best arguments for organising header files as
> Plan 9 does is the mess that /usr/include has become on (l)unix.  It's
> almost 20MB on Suse 9.1.
>
> Here's an interesting exercise for people who don't see a problem with
> how (l)unix organises /usr/include:
>
> Ask someone (ideally a manager, the higher the rank, the better) to
> find out where under /usr/include on Linux the type time_t is defined
> and the signal SIGINT is declared without using grep or any
> equivalent; they should trace through the include files visually.  If
> they return with the correct answers and aren't disgusted with the
> mess under /usr/include, slap some pointy hair on them.
>
>

Re: [9fans] Include guards and multiple includes

[Joel Salomon]

On 10/20/06, Paul Lalonde <plalonde@telus.net> wrote:
> Ah well, there goes one argument for keeping the header soup clean.

A better argument comes from a recent post on comp.lang.c:
"automatically remove unused #includes from C source?" where the
fellow asks for a tool to automatically analyze C source to find these
unused includes.

--Joel

Re: [9fans] Include guards and multiple includes

[Charles Forsyth]

>>A better argument comes from a recent post on comp.lang.c:

perhaps another approach is constructive, in the sense of considering
what one's trying to achieve with the constructions, and using constructions
to suit, rather than a negative argument (nested #includes are slow to compile,
or there might be unused ones).

for instance, the plan 9 scheme might be said to result from observing that
the unit of shared modularity (in practice) in C code is `the library'.
so: there's one #include file per library.  one library might depend on another,
but not mutually (so #includes can be simply ordered, reflecting that dependency).
you need to know in your own programs which libraries are in use, because it's
C, and your code's global name space is affected by each library (so it makes
sense for you to include the dependent libraries explicitly).
you'll know if you get something out of order, or if it's missing,
because you'll get diagnostics, but only the
first time, and after that you can forget about it.
it's easy to grep. and so on.

the scheme where each thing.c has a thing.h might to be modelled on
programming languages with modules, but each thing.o isn't normally the
unit of re-use.  most projects collect them into libraries, i'd have said.
there might be more to it, though.

for the posix scheme, the rationale must surely be that hardly anyone remembers
all the right names, let alone the right order, and things are scattered enough
or unrelated to particular things (eg, stdlib.h doesn't in practice correspond to any
particular library, and there are many includes for the C library),
so we'll let people slap them in any old way and let the system sort it out.
then there are so many variations from posix, in practice, that people add ./configure

Re: [9fans] Include guards and multiple includes

[Rogelio Serrano]

On 10/21/06, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm trying to convince some non-believers that include files should
> not include other include files, and that instead they should state
> their dependencies; they want hard data before they commit to such a
> scheme.
>
> Is there some study kicking around that I could point them at rather
> than re-factor our code base and time the resulting builds?  I know
> the plan9 headers largely follow this pattern.
>
> Paul

I think this has more to do with minimising the preprocessor logic. I
like the plan 9 include tree more than the traditional unix include
mess. In my programs I dont use macros anywhere. none. nada. zero.

If one could only get rid of the preprocessor...

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

Re: [9fans] Include guards and multiple includes

[erik quanstrom]

uh, ken did.

- erik

On Mon Oct 23 08:40:40 EDT 2006, rogelio.serrano@gmail.com wrote:
> 
> I think this has more to do with minimising the preprocessor logic. I
> like the plan 9 include tree more than the traditional unix include
> mess. In my programs I dont use macros anywhere. none. nada. zero.
> 
> If one could only get rid of the preprocessor...

Re: [9fans] Include guards and multiple includes

[Rogelio Serrano]

On 10/23/06, erik quanstrom <quanstro@coraid.com> wrote:
> uh, ken did.
>
> - erik

How?

>
> On Mon Oct 23 08:40:40 EDT 2006, rogelio.serrano@gmail.com wrote:
> >
> > I think this has more to do with minimising the preprocessor logic. I
> > like the plan 9 include tree more than the traditional unix include
> > mess. In my programs I dont use macros anywhere. none. nada. zero.
> >
> > If one could only get rid of the preprocessor...
>


-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

Re: [9fans] Include guards and multiple includes

[erik quanstrom]

look at /sys/src/cmd/cc/macbody and /sys/doc/compiler.^(ms ps).  ?c do
the "preprocessing" and parsing at the same time.  ?c only recognize 9
preprocessor symbols:

	ifdef
	ifndev
	else
	line
	define
	include
	undef
	pragma
	endif

- erik

Re: [9fans] Include guards and multiple includes

[Joel Salomon]

> ?c only recognize 9 preprocessor symbols:

I’ve missed __FILE__ and __LINE__ on occasion, but not enough to use the -p option to ?c.

--Joel

Re: [9fans] Include guards and multiple includes

[Charles Forsyth]

> ?c only recognize 9
> preprocessor symbols:
> 
> 	ifdef
> 	ifndev
> 	else
> 	line
> 	define
> 	include
> 	undef
> 	pragma
> 	endif

and that's easily more than too much

Re: [9fans] Include guards and multiple includes

[Joel Salomon]

> > ?c only recognize 9
> > preprocessor symbols:
<snip>
> 
> and that's easily more than too much

When metaprogramming techniques are needed, should we have the C
preprocessor or are we going to get a better tool?  (I know!  I know!
C++ templates!  ☺)

I’ve needed the full-power preprocessor in the past, when I had to
implement a miniature function-generating and function pointer table
populating mini-language (and it really was the most readable,
debuggable, and maintainable implementation of the spec possible).  I
didn’t need the various #ifs, but I did need ANSI-type macro
expansion; IIRC, ?c’s is different enough—and not so well documented
(looking at the implementation of the assert macro; how do you do
symbol catenation, or conversion to a string?)—that an implementation
of this trick would need subtle rewriting.

I don’t know if a “good” metaprogramming/code generation tool is
possible for a language with syntax more complicated than Lisp’s, but
even CPP has its use.

For the sort of conditional compilation admitted by “#ifdef Considered
Harmful”, what minimal set of CPP symbols would suffice?

--Joel

Re: [9fans] Include guards and multiple includes

[geoff]

I'd think the set of cpp keywords needed would be: ifdef, ifndef,
else, endif, define, undef, and include.  `line' is typically
generated by other preprocessors (e.g., yacc) not by people.  `pragma'
is compiler-dependent, and we have uses for it on Plan 9, but most
uses are in system-supplied headers files, not ones you'd write;
`#pragma incomplete' is an exception.

The main use we advocated in the paper for conditional compilation was
providing default values, thus:

#ifndef COPYSIZE
#define COPYSIZE 8192
#endif

and Henry Spencer suggested that this idiom might have been profitably
bundled up as `#override symbol value' (`#ifndefdef' in the paper).

The paper dates from an era of considerable diversity among Unix
systems and the beginnings of migration to ANSI/ISO C and POSIX, so it
was a time of transition.  These days I'm not using conditional
compilation or even cpp much.  Plan 9 has shown us better alternatives
to conditional compilation, and looking at some of my recent code, I
see that I #include headers and #define an occasional macro for some
expression and not much else.  enums have replaced #define for integer
constants, and that was always my main use for #define.

Re: [9fans] Include guards and multiple includes

[AtomicKobold Design]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On 10/20/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
>
> I think that one of the best arguments for organising header files as
> Plan 9 does is the mess that /usr/include has become on (l)unix.  It's
> almost 20MB on Suse 9.1.
>
> Here's an interesting exercise for people who don't see a problem with
> how (l)unix organises /usr/include:
>
> Ask someone (ideally a manager, the higher the rank, the better) to
> find out where under /usr/include on Linux the type time_t is defined
> and the signal SIGINT is declared without using grep or any
> equivalent; they should trace through the include files visually.  If
> they return with the correct answers and aren't disgusted with the
> mess under /usr/include, slap some pointy hair on them.
>
>
Yes I agree, they are even larger under S.L.E.D. 10, I believe like 35 MB,
or some such.
IMHO organizing header files.

As far as the above "exercise" no way w/o grep would I in a million years
wanna go through
/usr/include in a *nix system.

[-- Attachment #2: Type: text/html, Size: 1528 bytes --]