* [9fans] Include guards and multiple includes @ 2006-10-20 18:45 Paul Lalonde 2006-10-20 19:27 ` Joel Salomon ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Paul Lalonde @ 2006-10-20 18:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 18:45 [9fans] Include guards and multiple includes Paul Lalonde @ 2006-10-20 19:27 ` Joel Salomon 2006-10-20 20:18 ` Russ Cox 2006-10-20 23:15 ` geoff 2006-10-23 12:39 ` Rogelio Serrano 2 siblings, 1 reply; 17+ messages in thread From: Joel Salomon @ 2006-10-20 19:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 19:27 ` Joel Salomon @ 2006-10-20 20:18 ` Russ Cox 2006-10-20 20:37 ` Paul Lalonde 0 siblings, 1 reply; 17+ messages in thread From: Russ Cox @ 2006-10-20 20:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 20:18 ` Russ Cox @ 2006-10-20 20:37 ` Paul Lalonde 2006-10-22 16:37 ` Joel Salomon 0 siblings, 1 reply; 17+ messages in thread From: Paul Lalonde @ 2006-10-20 20:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 20:37 ` Paul Lalonde @ 2006-10-22 16:37 ` Joel Salomon 2006-10-23 12:29 ` Charles Forsyth 0 siblings, 1 reply; 17+ messages in thread From: Joel Salomon @ 2006-10-22 16:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-22 16:37 ` Joel Salomon @ 2006-10-23 12:29 ` Charles Forsyth 0 siblings, 0 replies; 17+ messages in thread From: Charles Forsyth @ 2006-10-23 12:29 UTC (permalink / raw) To: 9fans >>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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 18:45 [9fans] Include guards and multiple includes Paul Lalonde 2006-10-20 19:27 ` Joel Salomon @ 2006-10-20 23:15 ` geoff 2006-10-20 23:39 ` Bruce Ellis 2006-10-24 14:32 ` AtomicKobold Design 2006-10-23 12:39 ` Rogelio Serrano 2 siblings, 2 replies; 17+ messages in thread From: geoff @ 2006-10-20 23:15 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 23:15 ` geoff @ 2006-10-20 23:39 ` Bruce Ellis 2006-10-24 14:32 ` AtomicKobold Design 1 sibling, 0 replies; 17+ messages in thread From: Bruce Ellis @ 2006-10-20 23:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 23:15 ` geoff 2006-10-20 23:39 ` Bruce Ellis @ 2006-10-24 14:32 ` AtomicKobold Design 1 sibling, 0 replies; 17+ messages in thread From: AtomicKobold Design @ 2006-10-24 14:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-20 18:45 [9fans] Include guards and multiple includes Paul Lalonde 2006-10-20 19:27 ` Joel Salomon 2006-10-20 23:15 ` geoff @ 2006-10-23 12:39 ` Rogelio Serrano 2006-10-23 12:41 ` erik quanstrom 2 siblings, 1 reply; 17+ messages in thread From: Rogelio Serrano @ 2006-10-23 12:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 12:39 ` Rogelio Serrano @ 2006-10-23 12:41 ` erik quanstrom 2006-10-23 12:52 ` Rogelio Serrano 0 siblings, 1 reply; 17+ messages in thread From: erik quanstrom @ 2006-10-23 12:41 UTC (permalink / raw) To: 9fans 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... ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 12:41 ` erik quanstrom @ 2006-10-23 12:52 ` Rogelio Serrano 2006-10-23 13:26 ` erik quanstrom 0 siblings, 1 reply; 17+ messages in thread From: Rogelio Serrano @ 2006-10-23 12:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 12:52 ` Rogelio Serrano @ 2006-10-23 13:26 ` erik quanstrom 2006-10-23 15:30 ` Joel Salomon 2006-10-23 18:43 ` Charles Forsyth 0 siblings, 2 replies; 17+ messages in thread From: erik quanstrom @ 2006-10-23 13:26 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 13:26 ` erik quanstrom @ 2006-10-23 15:30 ` Joel Salomon 2006-10-23 18:43 ` Charles Forsyth 1 sibling, 0 replies; 17+ messages in thread From: Joel Salomon @ 2006-10-23 15:30 UTC (permalink / raw) To: 9fans > ?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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 13:26 ` erik quanstrom 2006-10-23 15:30 ` Joel Salomon @ 2006-10-23 18:43 ` Charles Forsyth 2006-10-23 19:12 ` Joel Salomon 1 sibling, 1 reply; 17+ messages in thread From: Charles Forsyth @ 2006-10-23 18:43 UTC (permalink / raw) To: 9fans > ?c only recognize 9 > preprocessor symbols: > > ifdef > ifndev > else > line > define > include > undef > pragma > endif and that's easily more than too much ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 18:43 ` Charles Forsyth @ 2006-10-23 19:12 ` Joel Salomon 2006-10-23 20:23 ` geoff 0 siblings, 1 reply; 17+ messages in thread From: Joel Salomon @ 2006-10-23 19:12 UTC (permalink / raw) To: 9fans > > ?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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] Include guards and multiple includes 2006-10-23 19:12 ` Joel Salomon @ 2006-10-23 20:23 ` geoff 0 siblings, 0 replies; 17+ messages in thread From: geoff @ 2006-10-23 20:23 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2006-10-24 14:32 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-10-20 18:45 [9fans] Include guards and multiple includes Paul Lalonde 2006-10-20 19:27 ` Joel Salomon 2006-10-20 20:18 ` Russ Cox 2006-10-20 20:37 ` Paul Lalonde 2006-10-22 16:37 ` Joel Salomon 2006-10-23 12:29 ` Charles Forsyth 2006-10-20 23:15 ` geoff 2006-10-20 23:39 ` Bruce Ellis 2006-10-24 14:32 ` AtomicKobold Design 2006-10-23 12:39 ` Rogelio Serrano 2006-10-23 12:41 ` erik quanstrom 2006-10-23 12:52 ` Rogelio Serrano 2006-10-23 13:26 ` erik quanstrom 2006-10-23 15:30 ` Joel Salomon 2006-10-23 18:43 ` Charles Forsyth 2006-10-23 19:12 ` Joel Salomon 2006-10-23 20:23 ` geoff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).