Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!uwvax!dogie!uwmcsd1!ig!agate!pasteur!helios.ee.lbl.gov!lll-tis!tjt
From: tjt@ati.tis.llnl.gov (Tim Tessin)
Newsgroups: comp.lang.c++
Subject: Re: Friends, static members
Message-ID: <22282@tis.llnl.gov>
Date: 21 Jun 88 16:12:03 GMT
References: <2668@tekred.TEK.COM>
Sender: news@tis.llnl.gov
Reply-To: tjt@ati.tis.llnl.gov (Tim Tessin)
Lines: 42

In article <2668@tekred.TEK.COM> kens@tekred.TEK.COM (Ken Spencer) writes:
> I have just started using c++, I'd like to here what people
> think of "Friends considered harmful", and also "Static members
> considered harmful"(not const static members).  
> Is friend generally used as a hack to get around some
> problems with C++?  How about static members, is this really a
> limited scope global object?
> 	Ken Spencer,Tekronix Inc.

Friends (of a class, not friend operators) are useful in allowing very
limited and specific access beyond what public, private and protected
allow.  This shows up in a module where you would have several classes which
intercommunicate and some are not useful outside of the module.  Example
is class Dlist which implements a doubly linked list.  Class Dlink
which is the actual implementation of the fwd and bkwd pointers is
mostly private and allows access by friend Dlist and friend Dlist_Iterator.
Dlink should not be allowed to be used by others just because it
was defined in the same module with Dlist and Dlist_Iterator
which are the "public" ways to fiddle with doubly linked lists.

Static members are "shared storage" for all instances of a 
given class.  They are not limited scope from the viewpoint of the
class, they obey the same scoping rules as any "normal" member (public,
private, etc).
Static members are critical for doing things like window classes which
need to init curses to get started.  A static counter (nwin) can count
all windows currently in existance and take care of cleanup when the
last window goes away.  Also, I have several static members in my
base class for "Object" which does all kinds of accounting for "Objects".
When my program terminates, I can tell how many objects were created,
destroyed, etc. and tell if I have forgot to clean up properly.  This 
has uncovered several bugs which I would never have found otherwise, 
especially when using reference counts for objects on lists and 
determining when to delete the object based on reference counts.  
Plug for C++: This would be next to impossible to get right in 
straight C.  (It can be done, but who wants to take on the administrative 
headache in the main line code!)

Tim Tessin - Lawrence Livermore National Laboratory  
PHONE: (415) 423-4560 
ARPA:  tjt@tis.llnl.gov
UUCP:  {ames,ihnp4,lll-crg,lll-lcc,mordor}!lll-tis!tjt