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: cygwin-patches-owner@sources.redhat.com
> [mailto:cygwin-patches-owner@sources.redhat.com]On Behalf Of Christopher
> Faylor
> Sent: Monday, October 15, 2001 6:37 PM
> To: cygwin-patches@cygwin.com
> Subject: Re: [PATCH] Move path_prefix_p declaration from cygheap.h to
> path.h
>
>
> There is a reason why that was a FIXME.
>

I figured as much; that's why I fixed it ;-).

> If you notice, with a few exceptions, I try not to have include files
> including include files.  I'm not sure that this is the correct approach
> but it is the current approach that we use in Cygwin.
>
> Also, for the most none of the header files are multiple-inclusion
> protected since the current approach should not use it.
>
> 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:

- Each object's header is protected from multiple-includes via the
ubiquitous #ifndef/#define/#endif mechanism (this is a "no-lose", even if
nothing else is done).
- Headers should contain mostly declarations, and a minimum of definitions.
- Each header file #includes, *within the multi-#include protection*, any
other headers it needs (e.g. a base class header, headers declaring the
object's data member and parameter types, etc.).
- Each implementation file #includes its own header, plus any other headers
it needs.  Note that it does *not* need to include any headers already
included by its own header, but no harm will come from doing so because of
the multi-#include protection.

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

a.h:
#once
#include <winnt.h>
#include <stdio.h>
class A {..};
#endif

b.h:
#once
#include "a.h"
// Note that I neither know nor care here that A is using
// stuff from winnt.h and stdio.h.
class B : public A {...};
#endif

c.h:
#once
#include "b.h"
class C : public B {...};
#endif

prog.cc:
// I only need to deal with C objects in here,
// I don't care what they need or where they came from.
#include "c.h"

void func()
{
  // Do something with Cs:
  C obj;
  obj.DoSomething();
}


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.

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


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