Projects for beginners

[Daniel Berlin]

On Fri, 2 Feb 2001, Branko [ISO-8859-2] Èibej wrote:

> Richard Kenner wrote:
>
> >     It also effectively sets those dependencies in concrete. If, for any
> >     reason, the dependencies change for a particular header, you have to
> >     change all sources that include it.
> >
> > From a conceptual point of view, you do anyway.  A header is a specification
> > of something which is implemented in a .c file.  If the specification
> > of something changes, you have to look at all callers to make sure they
> > reflect the change of specification.
<snip>
>
>
> O.K., that was considerably more than my $0.02, and since I'm not
> volunteering for any include-guard drudgery, I'll just leave the arguing
> to those that are.
>

As someone who is volunteering (in fact, i've already got a little script
to generate the header guards automatically based on the
filename+md5sum, just to make it unique, and wrap the header in them),
I'll further point out that if you change, fer instance, the underlying
implementation of how the bitmaps work, I shouldn't have to touch
anything, as long as the guarantees those functions provide me haven't
changed.
(IE bitmap_bit_p still tells me if a certain bit is set in a bitmap).

As it stands now, if your change to the underlying implementation causes
you to add a definition in some #include file you didn't have to have
before (say you use something from glimits.h), you've just broken every
file that doesn't include glimits.h before bitmap.h, for no good reason.

Even if you don't change the functions at all, you just add a single new
define

#define BITMAP_MAX_ELEMENTS INT_MAX

you've just broken everything that includes bitmap.h


--Dan