Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cluster!metro!otc!mikem
From: mikem@otc.otca.oz (Mike Mowbray)
Newsgroups: comp.lang.c++
Subject: Re: implementation of static local variables
Message-ID: <1356@otc.otca.oz>
Date: 19 Mar 90 00:26:58 GMT
References: <1350@otc.otca.oz>
Lines: 58


In article <1350@otc.otca.oz>, ruben@otc.otca.oz (Ruben Gonzalez) says:

 > [...] 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 function is a member. Therefore it
 > will be accessed and modified by all instances of that object.

Eh?? If this is true it's a bug. Example please. Static local variables
*inside member function implementations* shouldn't be visible outside that
function.

 > SLVs within member functions are therefore made redundant by normal
 > static member variables and should not exist.

Static local variables and static member variables are *different* :

	class Foo
	{
		static int  classlocal;  // visible within all member fns
	    public:
		int	show();
		void	blah();
	};

	int Foo::show()
	{
	    static int  funclocal;  // not visible to Foo::blah()

	    return  funclocal = classlocal;
	}


 > There is apparently no way to implement a local variable within a
 > member function of an object which persists across invocations whose
 > scope is limited to that particular instance of the object.

Correct. The "unit" for scoping such things is the class. That's what
data-abstraction and object-oriented programming are all about.

 > As far as I have been able to asertain the only way round this is to
 > create a non static member variable, and to use that.

I venture to suggest that it would better not to try to get around it, but
rather to alter your design to use objects.

 > 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 this is so, then the selection of classes may be incorrect. You might
try using a smaller class to abstract the functionality of the
"memberfunction-plus-data" in question.

		Mike Mowbray	    ACSnet: mikem@otc.oz
		Network R&D	    UUCP:   {uunet,mcvax}!otc.oz!mikem
		|||| OTC ||	    Phone:  (02) 287-4104
				    Snail:  GPO Box 7000, Sydney, Australia