static variables in methods
-
Don't you find that omission completely indefensable? Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
Tom Archer wrote: Don't you find that omission completely indefensable? Yes, while you can fake it by putting static variables in the class; it doesn't do anything for variables you would like to keep localized only to the method. Maybe we can see it in v.next? :) James Simplicity Rules!
-
Tom Archer wrote: Don't you find that omission completely indefensable? Yes, while you can fake it by putting static variables in the class; it doesn't do anything for variables you would like to keep localized only to the method. Maybe we can see it in v.next? :) James Simplicity Rules!
In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. I don't know if a C# incarnation would follow the same pattern. In C++ I have never found a good reason to use the feature unless it was for returning the reference to a static object that required more aggressive initialization than just plain assignment or to defer potentially expensive initialization of such an object until it was actually used (which could be never). Regards
-
In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. I don't know if a C# incarnation would follow the same pattern. In C++ I have never found a good reason to use the feature unless it was for returning the reference to a static object that required more aggressive initialization than just plain assignment or to defer potentially expensive initialization of such an object until it was actually used (which could be never). Regards
Neil Van Note wrote: In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. Doh! You're right here; guess a regular class-level variable would be the solution ;P James Simplicity Rules!
-
On what a recursive function is or when you'd use one or ...? Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
Tom Archer wrote: On what a recursive function is or when you'd use one or ...? I think this is Tom trying to be funny. :-D Nick Parker
-
In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. I don't know if a C# incarnation would follow the same pattern. In C++ I have never found a good reason to use the feature unless it was for returning the reference to a static object that required more aggressive initialization than just plain assignment or to defer potentially expensive initialization of such an object until it was actually used (which could be never). Regards
Neil Van Note wrote: In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. I disagree. You're making the assumption that the class will be instantiated many times. Neil Van Note wrote: In C++ I have never found a good reason to use the feature One example is how window procs were/are written without MFC. Another example if when iterating over a chain of entities where each function call works on a given link and a static variable is used to keep track of current position. Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
-
Neil Van Note wrote: In C++, static locals are shared among all instances of a class, not very useful for state information of a recursive function. I disagree. You're making the assumption that the class will be instantiated many times. Neil Van Note wrote: In C++ I have never found a good reason to use the feature One example is how window procs were/are written without MFC. Another example if when iterating over a chain of entities where each function call works on a given link and a static variable is used to keep track of current position. Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
Tom Archer wrote: I disagree. You're making the assumption that the class will be instantiated many times. In this case, I am. And you are assuming the class is a singleton, this was not noted in the discussion, and I have to assume that it is not and point the fact out. I code very defensively. Tom Archer wrote: One example is how window procs were/are written without MFC What does a local static have to do with the implementation of a class borne window procedure? This can be achieved very easily without it, and prove to be much more reusable. Tom Archer wrote: Another example if when iterating over a chain of entities where each function call works on a given link and a static variable is used to keep track of current position I cannot picture a situation where it would be used this way and prove more elegant than other straight forward solutions. Do you have an example? Regards
-
What purpose would be served by making a local scope variable static? Nish
The posting stats are now in PDF:- http://www.busterboy.org/codeproject/ Feel free to make your comments. Updated - May 04th, Saturday
-
Static variables sometimes are very usefull. You can use it or not... but in my opinion programmer should decided what he wants to use (in this case simply language dosn't support it - that's a pity) Tomiga
The language supports class scope static variables; I don't see any reason why it should go any further. I have yet to see an instance, from an OOP standpoint, where it would beneficial to do otherwise. Regards
-
Don't you find that omission completely indefensable? Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
IIRC, there are two reasons we didn't do it: 1) You don't get much additional utility over an instance or static variable. 2) They tend to cause subtle problems when you start dealing with multi-threaded use. They're also harder to find when you're looking for such issues.
-
Helps when writing recursive functions Cheers, Tom Archer Author, Inside C# Author, Visual C++.NET Bible A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
And can lead to several multithreaded problems if not carefully coded... Crivo Automated Credit Assessment