Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!ukc!etive!lfcs!db
From: db@lfcs.ed.ac.uk (Dave Berry)
Newsgroups: comp.lang.c++
Subject: Re: information hiding
Message-ID: <2465@etive.ed.ac.uk>
Date: 29 Jun 89 17:53:29 GMT
References: <6031@watdcsu.waterloo.edu> <6590164@hplsla.HP.COM> <1421@cbnewsc.ATT.COM> <7709@spool.cs.wisc.edu>
Sender: news@etive.ed.ac.uk
Reply-To: db@lfcs.ed.ac.uk (Dave Berry)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Lines: 33

In article <7709@spool.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
> [An explanation of why class definitions must include private members,
>  so that the compiler knows the size of the class.]

This doesn't explain why private function members must be included.
It's a real pain to have to recompile a large part of a program just
because you've added a private function to do some internal processing.

Of course you could write the function at the top level and make it take
the relevant object as an argument, but this defeats some of the purpose
of using classes.

I'd like to be able to define private member functions outside the
class, e.g.

private Result* Foo::foo (Bar*, Stool*);

Then only the changed .c file would need to be recompiled.


Other approaches to this would be to use a separate header file to store
the private member functions, and to write your makefile so that only the
relevant .c file was recompiled when the private .h file was changed.
Unfortunately this wouldn't work with  makedepend, which I use a lot.

There are several ways that a C++ environment could handle this neatly,
providing the facilities of both make and makedepend, but allowing
private functions to be defined outside the class would be more portable.

Dave Berry, Laboratory for Foundations      db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
    of Computer Science, Edinburgh Uni.	    <Atlantic Ocean>!mcvax!ukc!lfcs!db

          "It's not a good omen when goldfish commit suicide."