Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!ericom!eua.ericsson.se!euamts
From: euamts@eua.ericsson.se (Mats Henricson)
Newsgroups: comp.lang.c++
Subject: Re: A GNU Makefile (was: ... header files **and** inline management)
Message-ID: <1991Mar4.085153.13371@eua.ericsson.se>
Date: 4 Mar 91 08:51:53 GMT
References: <1991Feb11.081550.18057@eua.ericsson.se> <3943@lupine.NCD.COM> <1991Feb20.083327.2028@eua.ericsson.se> <4187@lupine.NCD.COM>
Sender: news@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Lines: 95

rfg@NCD.COM (Ron Guilmette) writes:

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

Quite a lot. It took me perhaps 2 weeks to specify the .h-file for a large
class (approx 50 final pages of code). And I enjoyed the work, since I think
that was when I was constructing something. The implementation was aslo OK,
but not as inspiring since I knew all the way almost exactly what to do.
I kind of see it as travelling - planning is the best thing. When you
finally take off, you know it's soon over.

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

Yo.

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

I may be very lycky to be able to keep multiple editors open at the same
time, and a screen big enough to look at two files at the same time, but
that must soon be default for programmers, and programming environments not
designed for multiple editors open at the same time must be pretty out of
date.

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

I find hacking OK, but my boss would rightly be screaming at me if I did.
At LOOK '91 in Denmark recently I listened to Steven Weiss, and he pointed
out that "A quality system is a system that is easy to maintain". My bitter
experience is that hacking may seem to give quality software, but if you
look at it from the maintenance point of view, it's not. I'm paid to do
quality software, and will do so carefully my way, since I'm not a hacker,
nor a specially good programmer (I'm still looking at the Andrew Koenig
paper on Function Objects in The C++ Journal * summer 1990, since my mind
just refuses to grasp how this rediculously short piece of code actually
works :-!  ).

>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 think you can justify to the money department at your company, that
they will make money if they buy you a larger monitor since you will be
more efficient that way.

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

OK! It's a free world after all...

>-- 

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

Mats Henricson euamts@eua.ericsson.se