This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Move path_prefix_p declaration from cygheap.h to path.h


----- 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]