Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!think!mintaka!bloom-beacon!eru!luth!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: implementation of static local variables
Keywords: static local variable
Message-ID: <3790@tukki.jyu.fi>
Date: 16 Mar 90 09:20:23 GMT
References: <1350@otc.otca.oz>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 86

In article <1350@otc.otca.oz> ruben@otc.otca.oz (Ruben Gonzalez) writes:
>
>	The general argument for the existence of local static variables
>primarily involves that  of modular cohesiveness.
> ...
>The problem arises in C++ with the way in which static local variables
>are implemented for non static member functions. At the moment any static local
>variable (SLV) belonging to a non static member function is treated as
>if it were a normal static member variable of the object of which the
                             (should be 'class':)  ^^^^^^
>function is a member. Therefore it will be accessed and modified by all
>instances of that object. SLVs within member functions are therefore
                   ^^^^^^ (should be 'class')
>made redundant by normal static member variables and should not exist.

They are certainly not redundant. The question below that I have
marked '[*]' applies exactly to this distinction.
Unless I am badly mistaken, the visibility of static variables
declared in a member function is restricted to that function
(just like in an ordinary function).

(Even in the rest of the original article, 'object' is always used
when 'class' is meant.)

> ...
>	The problem is that modular cohesion is destroyed. Why
>should I have to make a variable visible to an entire
>object when it is only used by one member function? [*] [...]
> [...]  If for
>some reason there is a better way so that I
>don't have to violate the most basic rule in
>the book about modular programming, or at least
>a half decent reason for why it must be so,
>please let me know.

There is a valid point in the original article, although it also
shows non-understanding of the principles of _object-oriented_
programming. Let's try to clarify a little.

First of all, there is only one instance of each member function
of a class, no matter whether it is "static" or not.
Being static means only that the function can be invoked directly
(without reference to any instance of its class) and that 'this'
is not implicitly defined within the function.
For a data member, "static" means a _class variable_ (in e.g. Smalltalk
vocabulary), while otherwise it is an _instance variable_.
(This is an example of C++ overloading the same syntax with umpteen
subtlely different meanings.)

What Gonzalez is missing in C++ are instance variables that are visible
to one member function only. This would be more sensible if generalised
a little: visible only to some group of member functions. In any case,
the declaration of such instance variables (data members) would belong
to the class definition, _not_ to the member function definition -
otherwise the compiler would not know from a class definition even what
the size of an instance should be!

C++ already has the visibility attributes 'public', 'protected', and 'private'.
Gonzalez's requirement would mean that visibility could be limited even
further from 'private'. The utility would perhaps not be great enough
to justify the added complexity. Further, should some special member
functions such as constructors, destructor and assignment always be
automatically allowed to access "limited" data members?

Fortunately, there appears to be at least one not very inconvenient way
to accomplish the desired effect without modifying C++.
Suppose you would like to allow only the member functions 'zip' and 'zap'
to access the data members 'gold' and 'silver' of the class 'treasury'.
The trick is to define an "auxiliary class", say 'precious', such that
'gold' and 'silver' are _private_ data members of 'precious' and there
is a data member of type 'precious' in 'treasury'. Also declare the functions
'treasury::zip' and 'treasury::zap' to be friends of 'precious'.
That should essentially be it. (The auxiliary class can even be anonymous,
so you spare yourself the invention of one name.)

Apart from C++, there was an approach to different views of the same object
in Edward Sciore's paper "Object specialization". See recent postings
in the comp.object group.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)