On Thu, Dec 19, 2013 at 11:48:15AM -0500, Alan Stern wrote: > On Thu, 19 Dec 2013 josh@xxxxxxxxxxxxxxxx wrote: > > > > Of course, people have varying opinions on this issue. As far as I > > > know, there is no fixed policy in the kernel about nested includes. > > > > True. I personally prefer the policy of making all headers > > self-contained, and then only including headers that define things used > > in the source file. That has the advantage of not including any > > unnecessary headers if the dependencies shrink, and not requiring > > changes to multiple source files if the dependencies grow. > > > > Any particular objection to making the headers self-contained? > > I guess it depends on what you mean by "self-contained". The only > reasonable definition I can think of at the moment is that you don't > get any errors or warnings when you compile the .h file by itself. Or, to look at it another way, you can #include the .h file in a .c file without any other .h file, and successfully compile the .c file and use everything defined by the .h file. > For that matter, how can you tell that you are including only headers > that define things used in the source file? Remove each #include line, > one at a time, and see if you then get an error? Do you do this after > each change to the source file to make sure it remains true over time? > > My point is that the C language design and compiler infrastructure make > it virtually impossible to enforce any fixed policy. And that leaves aside all the preprocessor symbols that might change what a header defines. I'd argue for a best-effort policy, together with fixing headers whenever someone notices that they're *not* self-contained (in other words, they include a .h file to get a definition they need, and get a compile error). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
