|
Sorry mate. It's late and I am sooooooooo over this chapter
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
|
|
|
|
|
No problem Tom, let me ask you a question. Now that I see you have/are written/writing a book on Visual C++.NET, which language would you prefer to write an enterprise application in if asked to use the .NET Framework? Please don't say Fortran.NET or COBOL.NET
Nick Parker
|
|
|
|
|
Actually, the VC++ book is an MFC book. However, I've done enough in Managed Extensions that I would seriously think about combining MFC and Managed Extensions. MFC for the UI simply because I've used it for 10 years and ME for the cool classes .NET has to offer.
I'm not saying I would do that, but I'd give it some serious considerations under the right circumstances - especially if time was a major issue.
Cheers,
Tom Archer
Author - Inside C#, Visual C++.NET Bible
A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the af
|
|
|
|
|
As far as I know there is an appendinx in C# specification. (You can find it in your .NET installation folder in C#/C# langugae specification.doc
Tomiga
|
|
|
|
|
Is it possible to define something like variables in methods which have static modifier:
C++ example:
<br />
void MyFun()<br />
{<br />
static int i = 0;
i++;<br />
}<br />
|
|
|
|
|
No it doesn't, static can only be applied to Methods, Properties, Fields, Operators, and Constructors.
James
Simplicity Rules!
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Tom Archer wrote:
Helps when writing recursive functions
Oh! Can you further enlighten a confused newbie?
Nish
The posting stats are now in PDF:-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
Updated - May 04th, Saturday
|
|
|
|
|
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 ...?
Blast!!! Not that!!!!
I meant, I wanted to know how a static variable was going to be useful in a recursive function!!!
Nish!!!!
The posting stats are now in PDF:-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
Updated - May 04th, Saturday
|
|
|
|
|
That's a lot of excitement Nish. Are you sure you're taking your Lithium like you're supposed to
If you write a function that can call itself (a recursive function) one way to maintain state information is via static variables because they won't reinitilaize in the function's prolog.
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:
Are you sure you're taking your Lithium like you're supposed to
Gosh! Not that old AI bot thing again
Tom Archer wrote:
If you write a function that can call itself (a recursive function) one way to maintain state information is via static variables because they won't reinitilaize in the function's prolog.
I thought of that actually. But I thought since it was Tom Archer saying it, there ought to be a more complicated explantion to it
Didn;'t think that the obvious one would be the only one.
Nish
The posting stats are now in PDF:-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
Updated - May 04th, Saturday
|
|
|
|
|
Sometimes even I can't over-complicate something Seriously, maintaining state information across call boundaries is the main reason for using static variables within a method.
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.
Nick Parker
|
|
|
|
|
And can lead to several multithreaded problems if not carefully coded...
Crivo
Automated Credit Assessment
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
James
Simplicity Rules!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|