how to declare heap-allocated local field

andelero
andelero used Ask the Experts™
on
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.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
You can't have variables in C# outside of a class scope;

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?!

Author

Commented:
> 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.

Commented:
C++ & C# are languages of different generations, and, I think,
you must think in C# when you design a program for C#.
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

Commented:


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
}

Author

Commented:
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!
Commented:
I think that your first goal in using static variable is that the variable "has static duration".
Let's analyze the functionallity of your routine in C++:

CallCounter() returns each time, no matter from where is called, an integer that is +1 than
the value from previous call;

if your CallCounter() is a public function the functionallity is similar with the C#:

class myClass
{
  private static int iCallCount = 0;
  int CallCounter() { return ++iCallCount; }
}

because even if your variable has the scope of a function and in my example has the scope
of a class, in both cases the variable is not visible outside the class. Even more you can declare
the CallCounter static in C# with the same functionality (and becomes a class member not an object one).

if your CallCounter() is a private function I think there is nothing similar in C# because this
static variable iCallCount has the scope in your function and in C# it is not possible to have
static variables in the scope of a function.

As a conclusion static in C# is similar but is more limited in use than in C++, and is OOP compliant.

If is very important for you that the variable to be in heap, like _TAD_ said:

private static object count = 0;
private static int CallCounter() {
  int aux;
  aux = (int)count;
  count = ++aux;
  return aux;
}
Commented:


I guess I am a bit confused as to the reason why you would want a primitive variable stored on the heap?  Also, why a class level variable is offensive?

first and foremost, clas level variables are not only encouraged, but necessary.

How else would you overload constructors or create public properties?  In the good ol' days of C/C++ you could declare a variable in a local scope, drop it on the heap and then use pointers from anywhere and everywhere to point to and manipulate that value.  I never understood the point of that, I mean... why not just create the variable on a global basis anyway if that's the way it's going to be used.




At anyrate, Even objects declared and stored on the heap must be declared globally if you are going to use them outside of the local setting.  The nifty thing about C# is that is has a garbage collector.  You don't need to clean up after yourself.  If a variable goes out of scope and is stored on the heap, once it is out of scope it is free to be deleted and removed but the .net framework.

Author

Commented:
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. :)

Commented:


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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial