By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,184 Members | 1,390 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,184 IT Pros & Developers. It's quick & easy.

static variables?

P: n/a
Hi, I'm very new to C#, in fact I dont know anything about it. Im
having problem with its static variables. I used static variables alot
in C++, but seem like C# doesnt allow it inside a function the way C#
do, so how can you handle recursive functions that need static
variable.

One more thing, I have a variable like this:
OracleDataReader dr = GetDataReader(sql,conn, out errMsg);
How can I make dr static to use in my recursive function?

PS: Sorry to sound like a newbie, but Im actually am. I'd really
appreciate any help. Thanks

Nov 17 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a

"ye********@yahoo.com" <sh***********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi, I'm very new to C#, in fact I dont know anything about it. Im
having problem with its static variables. I used static variables alot
in C++, but seem like C# doesnt allow it inside a function the way C#
do, so how can you handle recursive functions that need static
variable.
You either pass the variable via a parameter or you use a local class field.
One more thing, I have a variable like this:
OracleDataReader dr = GetDataReader(sql,conn, out errMsg);
How can I make dr static to use in my recursive function?
public class C
{
....
OracleDataReader dr;
public void SetConnection()
{
dr = GetDataReader(sql, conn,out errMsg);
}
}
I'd strongly consider passing the reader to the next method as a parameter
however.
PS: Sorry to sound like a newbie, but Im actually am. I'd really
appreciate any help. Thanks

Nov 17 '05 #2

P: n/a
Yrsh, it kind of sucks that you can't declare static method variables, but
there you are. Declare them at class scope, as private fields, instead.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

"ye********@yahoo.com" <sh***********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi, I'm very new to C#, in fact I dont know anything about it. Im
having problem with its static variables. I used static variables alot
in C++, but seem like C# doesnt allow it inside a function the way C#
do, so how can you handle recursive functions that need static
variable.

One more thing, I have a variable like this:
OracleDataReader dr = GetDataReader(sql,conn, out errMsg);
How can I make dr static to use in my recursive function?

PS: Sorry to sound like a newbie, but Im actually am. I'd really
appreciate any help. Thanks

Nov 17 '05 #3

P: n/a
Thanks^^. But then wouldnt the dr be cleared each time the function is
called?

Here is my code, and I know it's wrong obviously, but cant figure out
how to fix it
private static bool Connection( string fromloc, string
toloc,OracleConnection conn)
{

string sql = "SELECT FLIGHTNO,LEGORDER,TOLOC FROM LEG WHERE FROMLOC =
'" + fromloc + "'";
string errMsg = "";

OracleDataReader dr = GetDataReader( sql, conn, out errMsg );
if ( errMsg != "" )
{
Console.WriteLine( errMsg );
return false;
}
if ( dr == null )
{
Console.WriteLine( "No result" );
return false;
}
while( dr.Read() )
{

if (dr[2].ToString()==toloc)
{
Console.WriteLine("flight: " + dr[0] + " legorder: " + dr[1]);
return true;
}
else
return(Connection(dr[2].ToString(),toloc,conn));
}
//dr.Close(); //close the DataReader
//dr.Dispose();
//conn.Close(

Nov 17 '05 #4

P: n/a
I do like static method variables but it appears the CLR does not
support it. VB.NET supports static method variables - its compiler
compiles such variables into private class fields.

Nov 17 '05 #5

P: n/a
>But then wouldnt the dr be cleared each time the function is
called?

Then you could initialize the var at declaration or in constructor.
If that is not posible, in the method check and only init if it is null.

Nov 17 '05 #6

P: n/a
Im trying to understand it.... Can anyone give me an example (any) or
better on the code I posted:

Task: given start-end location, find all possible connections.
If the function runs the first time and I get the first dr, then it
calls itself and i get the 2nd dr,... so on till the n dr. Then it goes
back from n to n-1.... to 1, how can I keep every dr from being deleted
each time the function called itself? Or is there a better way to solve
this prblem?

private static bool Connection( string fromloc, string
toloc,OracleConnection conn)
{

string sql = "SELECT FLIGHTNO,LEGORDER,TOLOC FROM LEG WHERE FROMLOC =
'" + fromloc + "'";
string errMsg = "";

OracleDataReader dr = GetDataReader( sql, conn, out errMsg );
if ( errMsg != "" )
{
Console.WriteLine( errMsg );
return false;
}

if ( dr == null )
{
Console.WriteLine( "No result" );
return false;
}

while( dr.Read() )
{

if (dr[2].ToString()==toloc)
{
Console.WriteLine("flight: " + dr[0] + " legorder: " + dr[1]);
return true;
}

else
return(Connection(dr[2].ToString(),toloc,conn));

}
}

Nov 17 '05 #7

P: n/a

"ye********@yahoo.com" <sh***********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Im trying to understand it.... Can anyone give me an example (any) or
better on the code I posted:

Task: given start-end location, find all possible connections.
If the function runs the first time and I get the first dr, then it
calls itself and i get the 2nd dr,... so on till the n dr. Then it goes
back from n to n-1.... to 1, how can I keep every dr from being deleted
each time the function called itself? Or is there a better way to solve
this prblem?


A local field would work.

Frankly, I don't see where you are going with your code here, why do you
need to keep old DataReaders around?
Nov 17 '05 #8

P: n/a

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Yrsh, it kind of sucks that you can't declare static method variables, but
there you are. Declare them at class scope, as private fields, instead.

Static variables are little more than fields with constrained access anyway.
I've never found them to be terribly useful and I do think they blur the
lines a bit much. I find that it is too easy to consider a field as local
state, even with the static marker. --
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

"ye********@yahoo.com" <sh***********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi, I'm very new to C#, in fact I dont know anything about it. Im
having problem with its static variables. I used static variables alot
in C++, but seem like C# doesnt allow it inside a function the way C#
do, so how can you handle recursive functions that need static
variable.

One more thing, I have a variable like this:
OracleDataReader dr = GetDataReader(sql,conn, out errMsg);
How can I make dr static to use in my recursive function?

PS: Sorry to sound like a newbie, but Im actually am. I'd really
appreciate any help. Thanks


Nov 17 '05 #9

P: n/a
If I have table flight with flightno, from, to,.. I want my program to
return all possible connections ,given from X and to Y.
Here is the solution I come up with:
1.Search all flights from X
For example I get:

flightno from to
1 X Y
2 X A
3 X B

2.Loop thru the result
a. If the flight's destination is Y, return this path
b. Else, Search all flights goes from this result's location (for
example: all flights from A)

I hope I make it clearer? Now you see why I want to keep the old
datareader?

Nov 17 '05 #10

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
Yrsh, it kind of sucks that you can't declare static method variables, but
there you are. Declare them at class scope, as private fields, instead.


Personally, I'm glad that static method variables don't exist. If a
method needs that much state (so it's hard to pass as parameters
recursively, for instance), it's usually a sign that that state should
be encapsulated in a class.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #11

P: n/a
> Personally, I'm glad that static method variables don't exist. If a
method needs that much state (so it's hard to pass as parameters
recursively, for instance), it's usually a sign that that state should
be encapsulated in a class.
That can be argued. Still, I like to have the freedom. Hey, I'm something of
a control freak!

Anyway, note that I only said "kind of." I'm not losing any sleep over it!

--

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
Yrsh, it kind of sucks that you can't declare static method variables,
but
there you are. Declare them at class scope, as private fields, instead.


Personally, I'm glad that static method variables don't exist. If a
method needs that much state (so it's hard to pass as parameters
recursively, for instance), it's usually a sign that that state should
be encapsulated in a class.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #12

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
Personally, I'm glad that static method variables don't exist. If a
method needs that much state (so it's hard to pass as parameters
recursively, for instance), it's usually a sign that that state should
be encapsulated in a class.


That can be argued. Still, I like to have the freedom. Hey, I'm something of
a control freak!


In that case, C++ is the language for you. C# stops you from doing all
kinds of things which are usually a bad idea - and as I say, I'm glad
about it.

Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #13

P: n/a
>Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.

I like static method var just because it frees me from worrying it
might be unintentionally accessed by something else. When I use a
method static var, what I actually want is an object state to which
access is restricted to a single method. If there is something like a
compile-time attribute that I can apply to a field to instruct the
compiler to emit a compile-time error if the field is accessed not by
one of the methods specified, no-one would use method static vars then.
That is my idea.

Thi

Nov 17 '05 #14

P: n/a
Truong Hong Thi wrote:
Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.

I like static method var just because it frees me from worrying it
might be unintentionally accessed by something else. When I use a
method static var, what I actually want is an object state to which
access is restricted to a single method. If there is something like a
compile-time attribute that I can apply to a field to instruct the
compiler to emit a compile-time error if the field is accessed not by
one of the methods specified, no-one would use method static vars then.
That is my idea.


While I can see that being useful, I think it's worth considering *why*
you want it to only be available to that method. Is it *fundamentally*
part of the state of the object (or type for a static method) or is it
really state which perhaps belongs somewhere else?

I know it's not always clear-cut, but I tend to find that when there
are variables like this, a redesign gives a more elegant solution.

Jon

Nov 17 '05 #15

P: n/a
Hi Jon,
In that case, C++ is the language for you. C# stops you from doing all
kinds of things which are usually a bad idea - and as I say, I'm glad
about it.
Nah. I prefer the ease of use with C#, the elegance of the syntax, and I can
live with the managed compromises. I was just wishing out loud. I can
certainly understand the reasons for the constraints. In this biz,
everything involves a certain amount of compromise. If I couldn't live with
that, I'd go crazy!

The number of possible permutations involved in the process of skinning a
cat are nearly infinite, and finding an elegant cat-skinning method is a
challenge I enjoy. :)
--

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
> Personally, I'm glad that static method variables don't exist. If a
> method needs that much state (so it's hard to pass as parameters
> recursively, for instance), it's usually a sign that that state should
> be encapsulated in a class.


That can be argued. Still, I like to have the freedom. Hey, I'm something
of
a control freak!


In that case, C++ is the language for you. C# stops you from doing all
kinds of things which are usually a bad idea - and as I say, I'm glad
about it.

Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #16

P: n/a
Hi Jon,

One other point I couldn't get off my mind:
Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.


This is a bit of an over-simplification. Methods have both state and
process. Variables in methods are certainly state, not process. So, the
difference betweeen methods and classes is more subtle that you seem to
propose. Still, as I mentioned earlier, compromises must always be made.
Lines must eventually be drawn somewhere. I am satisfied with the places
where Microsoft has drawn the ines in .Net. The important issue to me is,
can I do what I need to do with relative ease and high productivity using
these tools? And of course, the answer is a resounding "yes."

--
:-D,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition
Nov 17 '05 #17

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
One other point I couldn't get off my mind:
Philosophically, methods are actions - they don't have state when
they're not on the stack. Objects and types *do* have state, and that's
where C# forces you to put that state.
This is a bit of an over-simplification. Methods have both state and
process. Variables in methods are certainly state, not process.


Yes - but only when they're on the stack (i.e. either running or ready
to run when a method they've called returns).
So, the difference betweeen methods and classes is more subtle that
you seem to propose.
Not with the difference above - a method which is not executing (and
nowhere on the stack) doesn't have any state, which is consistent with
real life - an action itself doesn't tend to have state apart from when
it's happening. (If I'm "going to the shop" I know where I happen to
be, but the concept of "going to the shop" itself doesn't have state.)
Still, as I mentioned earlier, compromises must always be made.
Lines must eventually be drawn somewhere. I am satisfied with the places
where Microsoft has drawn the ines in .Net. The important issue to me is,
can I do what I need to do with relative ease and high productivity using
these tools? And of course, the answer is a resounding "yes."


Gooodo :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #18

P: n/a
> Not with the difference above - a method which is not executing (and
nowhere on the stack) doesn't have any state, which is consistent with
real life - an action itself doesn't tend to have state apart from when
it's happening. (If I'm "going to the shop" I know where I happen to
be, but the concept of "going to the shop" itself doesn't have state.)
Neither does a class which is not instantiated (and nowhere on the stack).

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
One other point I couldn't get off my mind:
> Philosophically, methods are actions - they don't have state when
> they're not on the stack. Objects and types *do* have state, and that's
> where C# forces you to put that state.


This is a bit of an over-simplification. Methods have both state and
process. Variables in methods are certainly state, not process.


Yes - but only when they're on the stack (i.e. either running or ready
to run when a method they've called returns).
So, the difference betweeen methods and classes is more subtle that
you seem to propose.


Not with the difference above - a method which is not executing (and
nowhere on the stack) doesn't have any state, which is consistent with
real life - an action itself doesn't tend to have state apart from when
it's happening. (If I'm "going to the shop" I know where I happen to
be, but the concept of "going to the shop" itself doesn't have state.)
Still, as I mentioned earlier, compromises must always be made.
Lines must eventually be drawn somewhere. I am satisfied with the places
where Microsoft has drawn the ines in .Net. The important issue to me is,
can I do what I need to do with relative ease and high productivity using
these tools? And of course, the answer is a resounding "yes."


Gooodo :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #19

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
Not with the difference above - a method which is not executing (and
nowhere on the stack) doesn't have any state, which is consistent with
real life - an action itself doesn't tend to have state apart from when
it's happening. (If I'm "going to the shop" I know where I happen to
be, but the concept of "going to the shop" itself doesn't have state.)


Neither does a class which is not instantiated (and nowhere on the stack).


The type itself can have state, although as we've said elsewhere, it's
generally not a good idea to have publicly mutable state. However, the
Process type effectively has "state" in terms of "the currently running
processes" - I don't see anything inconsistent in that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #20

P: n/a
Well, Jon, I'm tired of arguing about it. See you tomorrow, buddy!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
> Not with the difference above - a method which is not executing (and
> nowhere on the stack) doesn't have any state, which is consistent with
> real life - an action itself doesn't tend to have state apart from when
> it's happening. (If I'm "going to the shop" I know where I happen to
> be, but the concept of "going to the shop" itself doesn't have state.)


Neither does a class which is not instantiated (and nowhere on the
stack).


The type itself can have state, although as we've said elsewhere, it's
generally not a good idea to have publicly mutable state. However, the
Process type effectively has "state" in terms of "the currently running
processes" - I don't see anything inconsistent in that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #21

P: n/a
Correct me if I'm wrong, but I seem to remember Anders Hejlsberg saying
something about "considering" the idea of being able to restrict access
to bits of object state to only certain methods. I believe he said that
it had appeal in certain situations, although I'd be stretching my
(awful) memory way to far to speculate on what those were.

Or I could be imagining the whole thing. Anyone else remember that
remark?

Nov 17 '05 #22

P: n/a
Bruce Wood wrote:
Correct me if I'm wrong, but I seem to remember Anders Hejlsberg saying
something about "considering" the idea of being able to restrict access
to bits of object state to only certain methods. I believe he said that
it had appeal in certain situations, although I'd be stretching my
(awful) memory way to far to speculate on what those were.

Or I could be imagining the whole thing. Anyone else remember that
remark?


I don't remember hearing it, but I'd certainly welcome it (and have
submitted it as a request) for properties - it would be very nice to be
able to do something like:

public int Foo
{
private int foo;
public get { return foo; }
private set { foo = value; }
}

which would *force* code in the class itself to go through the
property.

Jon

Nov 17 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.