On Tuesday 11 June 2002 16:52, george anzinger wrote:
> Linus Torvalds wrote:
> > The real #include hell comes, to a large degree, from the fact that we
> > like inline functions. Which have many wonderful properties, but they have
> > the same nasty property typedefs have: they require full type information
> > and cannot be predeclared.
> >
> > And while I'd like to avoid #include hell, I'm not willing to replace
> > inline functions with #define's to avoid it ;^p
>
> On wonders if it might be useful to split header files into
> say for example, list_d.h and list_i.h with the declarations
> in the "_d.h" and inlines in the "_i.h". Then we could move
> the "_i.h" includes to the end of the include list. Yeah, I
> know, too many includes in includes to work.
No, it does work, and it works very well. The winning strategy is to
split out heavily referenced data declarations from any dependent
function declarations, and give them their own headers, also included
from the orginal headers. The normal 'compile this header once'
mechanism makes this work smoothly and that's optimized by cpp so
compile speed impact is negigible. In many cases only the data
declaration is needed, so it's possible we might even see a slight
speedup.
The tradeoff of a few more header files (and it's only a few) against
a lot more sanity is well worth it. I demonstrated the technique in
my 'early_page' patch set, which lets you declare struct page as the
first thing in mm.h. and I suppose I should dust that off, update it
to 2.5 and submit it.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:22 EST