This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: [PATCH] Move path_prefix_p declaration from cygheap.h to path.h
- To: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>,<cygwin-patches at cygwin dot com>
- Subject: Re: [PATCH] Move path_prefix_p declaration from cygheap.h to path.h
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Tue, 16 Oct 2001 12:31:58 +1000
- References: <NCBBIHCHBLCMLBLOBONKCEPLCGAA.g.r.vansickle@worldnet.att.net>
----- Original Message -----
From: "Gary R. Van Sickle" <g.r.vansickle@worldnet.att.net>
> > The FIXME was really hiding a larger issue of what to do about
header
> > file use in cygwin. So, just having cygheap.h include path.h is not
> > a real solution for this problem.
> >
>
> It does solve the short-term problem of moving the declaration to the
header
> of its implementation where it really belongs, and it's a very, very
small
> step towards the long-term issue you present. In an object-oriented C
or
> C++ design, especially a large one such as Cygwin, things work best
with a
> setup like this:
If I understood Chris's email correctly, he was saying that we was not
sure which coding standard for header inclusion was best for cygwin -
not that that patch didn't solve a particular issue.
If the cygwin header coding standard specifies no automatic inclusions,
then this is actually a step in the wrong direction.
And *deciding* on the best header inclusion coding standard is likely
the time consuming issue.
[skip list of benefits for 'smart' headers]
> > I "cleaned up" header file usage a while ago by eliminating a
monolithic
> > winsup.h but, in the process, I just ended up with nearly every
source
> > file requiring nearly every header file -- which was no real
improvement.
> >
>
> Right, that's the problem the above arrangement is designed to solve.
Any
> particular file, be it .h or .c/.cc, only needs to include the headers
of
> the objects it is using, and *not* any headers required by *those*
headers.
> Example in C++, but it applies equally to OO designs in C (using
'#once'
> here to indicate of '#ifndef/#define' pairs in a vain attempt at
brevity):
Ah, thats 'a' problem the above arrangement solves. It creates it's own
issues though. Off the top of my head
* longer compile times (even if precompiled headers are supported - and
gcc 2.95 doesn't support 'em - due to the increased memory load).
* Can lead to scope related coding errors when a incorrect symbol
actually matches one in an auto-included header.
> As you can see, this scheme completely eliminates the nightmare of
having to
> keep track of what headers your header's header's need. Furthermore,
> nothing ends up getting broke during the conversion, since you can
always
> list whatever headers you want to, and the multi-#include protection
takes
> care of itself.
The multi include protection, IMO is _always_ a good idea, either that
or multi-include ERROR's, if thats appropriate to support the coding
style.
> > So, header file layout needs to be addressed again at some point
when we
> > have the luxury of not thinking about bug fixes.
> >
>
> In my many years of writing code for many different platforms in many
> different languages, I'm not embarrased to admit that I've never once
had
> that luxury; I'd wager that none here have.
>
> In this particular case, since I'm not a whole lot of use yet in
fixing
> bugs, how about me working on the header issue?
I'm cool with that :}, but working from my assumption about Chris's
point, we have a coding decision to make first.
Assuming Chris is happy to have this discussion now:
My vote is for something like the following.
* Headers never define derived classes and base classes in the same
file.
* Headers never define more than 1 derived class.
(ie a header _can_ define 2 base classes, which is sometimes
appropriate).
* Base classe headers can auto-include headers that they _require_. This
is to ensure that the _correct_ header if multiple headers define the
same symbol is included.
* Derived class headers, or pure C headers do not auto-include other
headers.
* Headers list in the comments at the top the header files needed to
parse them.
An alternative that I'd be just as happy with is
* Headers never define derived classes and base classes in the same
file.
* Headers never define more than 1 derived class.
(ie a header _can_ define 2 base classes, which is sometimes
appropriate).
* All headers auto-include headers that they _require_.
* Base class headers _never_ auto-include the headers for their own
derived classes.
The key thing I'm trying to address here Gary and Chris, is that the
issue in cygwin is not with auto-inclusion of headers!
Rather the issue is that with a .cc file depending on a large number of
headers - directly or indirectly - results in trivial changes that
really only affect one or two .cc files rebuilding the whole d**n lot.
So the solution is to reduce the cross-dependency *without* affecting
the class hierarchy (unless it becomes obvious during the process that
something can be improved...)
I.e. Including a header for class foo, and also getting class bar :
public foo, means you need the headers for parsing the types in class
bar as well. This has just increased your dependency tree. (again: this
is irrespective of auto-inclusion).
Rob