Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: A GNU Makefile (was: ... header files **and** inline management)
Message-ID: <4187@lupine.NCD.COM>
Date: 2 Mar 91 18:59:33 GMT
References: <1991Feb11.081550.18057@eua.ericsson.se> <3943@lupine.NCD.COM> <1991Feb20.083327.2028@eua.ericsson.se>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 59

In article <1991Feb20.083327.2028@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes:
>
>>And you never go back and make any changes to the "interface" part once
>>you have written it for the first time!?!?!?!
>
>Of course I do! But, if you put enough work down on the header-file, you
>don't have to change it *that* often to justify any extra feature like the
>one you have suggested.

How much work would constitute "enough work" so that you would try to use
a clever Makefile to eliminate some or all of that work?  (Keep in mind
that the clever Makefile was already provided, so you don't even have to
develop it.)

Now perhaps you code your "interface parts" very very carefully, right
from the start, and perhaps this means that you very rarely have to
change even so much as a comma in them.  That's fine.  In that case,
I agree that you would not benefit much from the Makefile that I posted.

Likewise, if you use Emacs or some other editor that allows you to easily
edit multiple files at one time, then the benefit of my scheme (based upon
the tricky Makefile) is diminished somewhat.

However if you are "evolving" some brand new code (in fast and furious mode,
sometimes called "hacking") then you may often find that you need to make
some change which affects *both* the interface and the implementation parts
(e.g. adding an additional member function or data member to a class
definition and then adding some references to the new member in some of
the implementation parts of existing member functions, or adding one
more parameter to the declaration of some member function within the
class declaration and also adding the additional parameter to the
implementation of that member function).

All I know is that my own experience of developing new C++ code led me
to feel that it would often be that case that I would need to make some
change which would need to be reflected in *both* the interface part and
in the implementation part.  I found myself repeatedly doing:

		start editor to edit .C file
		modify .C file
		exit editor (saving changes)
		start editor to edit corresponding .h file
		modify .h file
		exit editor (saving changes)
		start editor to edit .C file
		.
		.
		.

I no longer do that.  These days, when I am working on "refining" some
class, I have everything which relates to that class (both its interface
and its implementation) in one single file.  To "refine" the class, I
always know that I only have to edit one particular file.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.