|
From: | David Ayers |
Subject: | Re: Header cleanliness [was: removing the 'makeinstall'-->'makeall' dependency] |
Date: | Tue, 17 Dec 2002 10:42:19 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 |
Alexander Malmberg wrote:
With the exception of GSWeb (in which things are currenlty more complicated) I would be all for both of these suggestions.* A header must be self-contained. If it needs any definition from another header, it must include it itself. To catch violations of this (which are very annoying, and I know from experience that it's easy to just include some extra headers in your app/tool until it works and then forget about it instead of fixing it), each .m file should include its corresponding header before doing anything else. * A header should include as few other headers as possible. Use @class instead. This speeds up compilation, doesn't pollute the user's namespace, and doesn't break things when a header suddenly stops including some other header (I've been bitten by this as well; better to sort it all out at once). Comments welcome.
I really don't want to get off the topic too much but... :-)Another thing I keep wondering about, is whether libraries and frameworks (should/must) include thier own project headers with a prefix. i.e. why NSArray.m includes:
#include <Foundation/NSArray.h> instead of #include "NSArray.h" and why NSArray.h includes: #include <Foundation/NSRange.h> instead of #include "NSRange.h"I know gnustep make changes the search order so that the source headers are found before the installed headers but if a header is ever removed from the source, make will still pick up the installed header. On the other hand, the second scheme also works well and I have a feeling that it is more correct. But maybe I'm missing something, enlighten me please :-)
Cheers, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |