Date: Wed, 08 May 2002 12:33:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ian <freebsd@damnhippie.dyndns.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: /usr/include/netinet/in.h Message-ID: <3CD97D9D.E4E734D5@mindspring.com> References: <B8FED3FA.CC8C%freebsd@damnhippie.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian wrote: > > The general rule is "including includes from includes is bad". > > Okay, it's time to point out that these are opinions, not rules, and > differing opinions exist. Of course they are opinions. They just happen to be, in most cases, codified by the IEEE POSIX and Single Unix Specification standards, however, whose man pages for system interfaces dictate which headers *must* be included for the interfaces. > My opinion is that if a given header file requires some aspect of another > interface, that header should (nay, MUST) include what it needs for itself, > rather than relying on something external to "do the right thing". You mean "something external, like a professional programmer". > Why require thousands of programmers to remember all these interdependancies > as opposed to one programmer encoding the depenancy once where it belongs and > then everyone else can get on with their life and get some real coding done. Because it is their job to know such things, and it is why they "get the big bucks"? So that their code written on Linux will compile without errors on Solaris, FreeBSD, AIX, NetBSD, OpenBSD, HP/UX, etc.? Because "fixing" the broken portability of code by changing the OS is breaking it, not fixing? Because the sooner that a new programmer learns that there are differences between implementations on platforms, and learns to program to standards, rather than to implementations, the better off we will all be? > Within the context of a given project (E.G., FreeBSD) someone's opinion on > this matter may achieve the force of "a rule". Within the larger context of > software engineering in general there is no rule, not even a concensus, on > this issue. My opinion is *far far away* from the force of "a rule" within the FreeBSD project. However, I think that there is a general consensus against promiscuous includes. Including include files automatically because someone *may* use an interface which required both to be in scope is tantamount to mixing Magnesium powder in with the Sulfer powder, so that chemists who need both, and can only remember the Sulfer, get both when they need it. And then if there is Magnesium powder "in scope" when they add the acid, well, they had better just learn to use acid that doesn't react adversely with Magnesium... "Where did I put that Magnesium-proof Sulfuric Acid again?". I may *want* to redefine manifest constants, or provide wrapper versions of functions by renaming the real things and calling the renamed versions from my wrapper versions, so that calls to the code go through my instrumentation. Not permitting me to do redefinition between one "#include" and another "#include" because the second is embedded in the first *robs* me of language features which would allow me to do that. A "#define" doesn't work on an lvalue to another "#define". I guess I could: #define _FOO_H_ 1 #include <fee.h> #undef _FOO_H_ .. insert macro hackery here ... #include <foo.h> To avoid "fee.h" automatically including "foo.h" against my will, but, sheesh, working around the cure is worse than the disease! All to make up for programmers who are incapable of reading the documentation, but somehow supposedly still able to program otherwise correct code, despite their lack of knowledge regarding the interfaces they are using. Anyone who wants to be able to swing a dead cat at a keyboard, and then walk away with a running program, should probably stick to APL... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD97D9D.E4E734D5>