Path: utzoo!attcan!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: When to make member functions?
Keywords: member functions, c++
Message-ID: <1230@tukki.jyu.fi>
Date: 30 Aug 89 06:20:36 GMT
References: <1267@pc.ecn.purdue.edu> <2506@fai.UUCP> <565@hsi86.hsi.UUCP>
Reply-To: markku@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 53

In article <565@hsi86.hsi.UUCP> wright@hsi.com (Gary Wright) writes:
-In article <2506@fai.UUCP> kurtl@fai.fai.com (Kurt Luoto) writes:
->Since there are so many things that you can do with a graph, it seems silly
->to encumber a simple graph class with all kinds of algorithmic functions.
->On the other hand, in other OOP languages you have no choice. E.g. in Eiffel,
->functions only exist as members of some class.  What is appropriate for C++?
->(Honest, I am not trying to start any flame wars here.)
-
-1. Design an abstract graph class with no commitment to any 
-   particular implementation.
-2. Inherit from your abstract class, and define the implementation.
-3. Inherit once more from a specific implementation of your graph
-   class and add the computationally expensive algorithms at
-   this step.  This step may also include adding state to the
-   various nodes in the graph in order to implement some graph
-   algorithms.
-
-This is an over-simplification but [...]
- ...

Recommendations 1 and 2 above make sense,
but I think that recommendation 3 goes exactly the wrong way round.
The original question was about functions that are independent
of the particular realisation, i.e. written in terms of the general
public interface of the abstract graph class.
In my opinion, such functions should be _implemented_ in the abstract class.
This is both conceptually logical and avoids code duplication.
For safety's sake you could declare some or all of those functions
virtual if you might some day want to write essentially more efficient
versions of them for some specific cases.

My suggestion for the more general question (When to make functions
members of classes and when not?) is much more a matter of taste.
1. If a function needs to access private or protected members of the class,
   make it a member function unless there are strong logical reasons
   to the contrary (it must then be declared a friend, of course).
   There is some more technical discussion about this in Stroustrup's
   book (6.10).
2. If a function needs to access private or protected members of
   _several_ classes, make it a friend of all those classes;
   but if it is clearly most intimately connected with one class,
   make it a member of that one a friend of the others.
3. If a function needs no access to any private or protected class members,
   make it an ordinary function unless there are strong logical reasons
   for making it a member function of some class. (I think there are
   such reasons in the graph example.)

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland