andelero
asked on
how to declare heap-allocated local field
What is the C# version of:
int CallCounter() {
static int iCallCount = 0;
return ++iCallCount;
}
I realize that 'static' has different semantics in C#, but surely there is an alternative method to allocate a locally-scoped variable on the heap. Of course, I could always define the field at class-scope but that offends my sense of...well, everything. Any thoughts or advice appreciated.
int CallCounter() {
static int iCallCount = 0;
return ++iCallCount;
}
I realize that 'static' has different semantics in C#, but surely there is an alternative method to allocate a locally-scoped variable on the heap. Of course, I could always define the field at class-scope but that offends my sense of...well, everything. Any thoughts or advice appreciated.
ASKER
> You can't have variables in C# outside of a class scope;
Right, I know. The function CallCounter() is within a class.
> But with static you can declare in C# a static member of a
> class that can be used (more or less) like static in C++. :)
Since 'static' applies to the class and not the object, it's not appropriate for what I'd like to do.
Right, I know. The function CallCounter() is within a class.
> But with static you can declare in C# a static member of a
> class that can be used (more or less) like static in C++. :)
Since 'static' applies to the class and not the object, it's not appropriate for what I'd like to do.
C++ & C# are languages of different generations, and, I think,
you must think in C# when you design a program for C#.
you must think in C# when you design a program for C#.
Have you considdered boxing the int?
public class myClass
{
private object myBox; // is an object and stored on the heap
private int CallCounter()
{
int iCallCount = 0; // is an int and stored on the stack
myBox = (object) ++iCallCount; // boxes the int in an object
return (int) myBox; // returns the "unboxed" int
}
ASKER
Well no, but this code doesn't work and doesn't make much sense to me. My goals are two-fold: a) have a locally-scoped variable/field and b) have it allocated on the heap.
Your code will always set myBox to 1, since (as is the heart of the problem) iCallCount is always initialized to 0. Further, if I -were- to take your (intended) approach, why wouldn't I just do:
class myClass
{
int iCallCount = 0;
int CallCounter() { return ++iCallCount; }
}
Like I said in the original query, I know this works but it isn't very elegant and could be difficult to manage on a larger scale. I was hoping to find a C# idiom or approach that is the equivalent of the solution I'd use in C or C++. I'm completely new to C#, but it doesn't look promising!
Your code will always set myBox to 1, since (as is the heart of the problem) iCallCount is always initialized to 0. Further, if I -were- to take your (intended) approach, why wouldn't I just do:
class myClass
{
int iCallCount = 0;
int CallCounter() { return ++iCallCount; }
}
Like I said in the original query, I know this works but it isn't very elegant and could be difficult to manage on a larger scale. I was hoping to find a C# idiom or approach that is the equivalent of the solution I'd use in C or C++. I'm completely new to C#, but it doesn't look promising!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for your efforts here folks.
The short answer is that a) persistent local variables aren't supported by the language; and b) the alternative described in my original question (class-level variable) is the best option in lieu of.
As to why I (or anyone) would want to do this, the answer is simple: using a class-level field expands the scope of the variable unnecessarily and that isn't a very OO thing to do. That is, the only reason to expose what would otherwise be a function-level variable to the entire class is to alter its lifetime. I believe those attributes should be independent.
I -never- suggested that class-level fields didn't make sense or weren't appropriate for most uses, only that here the variable (in an information-hiding sense) only belonged one place, and that's in the method. Surely, you don't routinely rip out all method-local variables and stick them at the class level do you?
In any case, thanks again. Looks like I'll just have to live with it unless I can successfully lobby for a "persist" modifier for a future version. :)
The short answer is that a) persistent local variables aren't supported by the language; and b) the alternative described in my original question (class-level variable) is the best option in lieu of.
As to why I (or anyone) would want to do this, the answer is simple: using a class-level field expands the scope of the variable unnecessarily and that isn't a very OO thing to do. That is, the only reason to expose what would otherwise be a function-level variable to the entire class is to alter its lifetime. I believe those attributes should be independent.
I -never- suggested that class-level fields didn't make sense or weren't appropriate for most uses, only that here the variable (in an information-hiding sense) only belonged one place, and that's in the method. Surely, you don't routinely rip out all method-local variables and stick them at the class level do you?
In any case, thanks again. Looks like I'll just have to live with it unless I can successfully lobby for a "persist" modifier for a future version. :)
I understand your arguments/reasons for not wanting to expose a function level variable to an entire class. But, by appearences the variable you are trying to persist should be a property, not just a counting variable for some local loop.
What is it that you are trying to keep a count of that you need to call a function in order to do it (while yet not exposing the variable to other methods in that object)?
I guess I just want to get an understanding of what your design is (the big picture), because I may be petitioning MS to add a persist function/declaration as well.
But with static you can declare in C# a static member of a class that can be used
(more or less) like static in C++. :)
This kind of construnction is not really OOP and is not permited in C#.
I think is similar in Java?!