471,354 Members | 1,521 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,354 software developers and data experts.

static functions variables

What could be the possible reasons (technical/non technical) of not using lots of static functions or variables in a program keeping in mind that Framework by itself has tons of static functions and variables?
Feb 8 '06 #1
9 2066
If a method does not refer to any state, then it should probably be static as your making it clear it is not and does not need to be an instance method. This can also be more convenient to program against as you can call the static from anywhere in your app domain and don't need an obj instance first. It can also be a bit ~safer as you can't mistakenly change instance data on the type (unless you get a ref to one and go out of your way to change a field). Instance methods kinda tell you they need to be instance methods when you need to refer to instance state,

--
William Stacey [MVP]

"Pohihihi" <no*****@hotmail.com> wrote in message news:eK*************@TK2MSFTNGP09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using lots of static functions or variables in a program keeping in mind that Framework by itself has tons of static functions and variables?
Feb 8 '06 #2
There are no non-technical reasons. And the question is not exactly
well-put. Static functions and data are tools. Some tools are good for some
things, and others are good for other things. So, rather than asking why not
to use "lots of static functions," you should be asking when to use them,
and when not to. In other words, the real question is, "what are the
characteristics of static functions and data that affect my decision of when
to use them?"

Static data is not threadsafe straight out of the box, if you need to modify
it. It can be modified in a threadsafe way, but it requires a bit more work
to do. Static data is global to your application, which means if you change
it in one place, it changes for everything. This can be either good or bad,
depending upon whether or not you want this to happen. Remember that
encapsulation, one of the pillars of OOP, is there for a purpose. Static
functions are fine, as long as they don't need to work with instance data.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:eK*************@TK2MSFTNGP09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using
lots of static functions or variables in a program keeping in mind that
Framework by itself has tons of static functions and variables?

Feb 8 '06 #3
I guess you are right that question was not explained properly. I understand
the desig part of its use and when to and when not to use. What actually I
should have asked is that if I have lots of static functions/variables then
do thay create any memory problem (eating it all) or any performance issues?
What I understand is that because they are static they are in memory all the
time to server its users thus live all the time in memory.
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eE*************@TK2MSFTNGP09.phx.gbl...
There are no non-technical reasons. And the question is not exactly
well-put. Static functions and data are tools. Some tools are good for
some things, and others are good for other things. So, rather than asking
why not to use "lots of static functions," you should be asking when to
use them, and when not to. In other words, the real question is, "what are
the characteristics of static functions and data that affect my decision
of when to use them?"

Static data is not threadsafe straight out of the box, if you need to
modify it. It can be modified in a threadsafe way, but it requires a bit
more work to do. Static data is global to your application, which means if
you change it in one place, it changes for everything. This can be either
good or bad, depending upon whether or not you want this to happen.
Remember that encapsulation, one of the pillars of OOP, is there for a
purpose. Static functions are fine, as long as they don't need to work
with instance data.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:eK*************@TK2MSFTNGP09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using
lots of static functions or variables in a program keeping in mind that
Framework by itself has tons of static functions and variables?

Feb 9 '06 #4
| Static data is not threadsafe straight out of the box, if you need to
modify

I would add that no var is thread safe - instance or static does not really
matter. If a var is "read-write" by 2 or more threads, it needs some kind
of syncronization.
--wjs
Feb 9 '06 #5
William Stacey [MVP] <wi************@gmail.com> wrote:
| Static data is not threadsafe straight out of the box, if you need to
modify

I would add that no var is thread safe - instance or static does not really
matter. If a var is "read-write" by 2 or more threads, it needs some kind
of syncronization.


Unless it's got a ThreadStaticAttribute :)

--
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
Feb 9 '06 #6


Jon Skeet [C# MVP] wrote:
William Stacey [MVP] <wi************@gmail.com> wrote:
| Static data is not threadsafe straight out of the box, if you need to
modify

I would add that no var is thread safe - instance or static does not really
matter. If a var is "read-write" by 2 or more threads, it needs some kind
of syncronization.

Unless it's got a ThreadStaticAttribute :)

To be fair he did say "straight out of the box". Though I didn't get my
box. I downloaded VS... How can it be thread safe if there's no box?

Scott

too early in the morning.
Feb 9 '06 #7
If you got the blue box on a Monday, then I think it is. :)

--
William Stacey [MVP]
Feb 9 '06 #8
Hi Pohihihi,

Actually, static members use *less* memory than instance members, because
they exist at the time the assembly is loaded, and there is only one copy.
There's a bit more mumbo jumbo involved because of the framework, but bottom
line is, they are single instances of data. Still, keep in mind the other
characteristics of static members when making your determination. Sometimes
they are exactly the right tool to use. Sometimes they are exactly the wrong
tool.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:e0*************@TK2MSFTNGP11.phx.gbl...
I guess you are right that question was not explained properly. I
understand the desig part of its use and when to and when not to use. What
actually I should have asked is that if I have lots of static
functions/variables then do thay create any memory problem (eating it all)
or any performance issues? What I understand is that because they are
static they are in memory all the time to server its users thus live all
the time in memory.
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eE*************@TK2MSFTNGP09.phx.gbl...
There are no non-technical reasons. And the question is not exactly
well-put. Static functions and data are tools. Some tools are good for
some things, and others are good for other things. So, rather than asking
why not to use "lots of static functions," you should be asking when to
use them, and when not to. In other words, the real question is, "what
are the characteristics of static functions and data that affect my
decision of when to use them?"

Static data is not threadsafe straight out of the box, if you need to
modify it. It can be modified in a threadsafe way, but it requires a bit
more work to do. Static data is global to your application, which means
if you change it in one place, it changes for everything. This can be
either good or bad, depending upon whether or not you want this to
happen. Remember that encapsulation, one of the pillars of OOP, is there
for a purpose. Static functions are fine, as long as they don't need to
work with instance data.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:eK*************@TK2MSFTNGP09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using
lots of static functions or variables in a program keeping in mind that
Framework by itself has tons of static functions and variables?


Feb 9 '06 #9
thanks Kevin, that gives me the right thing I was looking for.
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ub**************@TK2MSFTNGP10.phx.gbl...
Hi Pohihihi,

Actually, static members use *less* memory than instance members, because
they exist at the time the assembly is loaded, and there is only one copy.
There's a bit more mumbo jumbo involved because of the framework, but
bottom line is, they are single instances of data. Still, keep in mind the
other characteristics of static members when making your determination.
Sometimes they are exactly the right tool to use. Sometimes they are
exactly the wrong tool.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:e0*************@TK2MSFTNGP11.phx.gbl...
I guess you are right that question was not explained properly. I
understand the desig part of its use and when to and when not to use. What
actually I should have asked is that if I have lots of static
functions/variables then do thay create any memory problem (eating it all)
or any performance issues? What I understand is that because they are
static they are in memory all the time to server its users thus live all
the time in memory.
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eE*************@TK2MSFTNGP09.phx.gbl...
There are no non-technical reasons. And the question is not exactly
well-put. Static functions and data are tools. Some tools are good for
some things, and others are good for other things. So, rather than
asking why not to use "lots of static functions," you should be asking
when to use them, and when not to. In other words, the real question is,
"what are the characteristics of static functions and data that affect
my decision of when to use them?"

Static data is not threadsafe straight out of the box, if you need to
modify it. It can be modified in a threadsafe way, but it requires a bit
more work to do. Static data is global to your application, which means
if you change it in one place, it changes for everything. This can be
either good or bad, depending upon whether or not you want this to
happen. Remember that encapsulation, one of the pillars of OOP, is there
for a purpose. Static functions are fine, as long as they don't need to
work with instance data.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <no*****@hotmail.com> wrote in message
news:eK*************@TK2MSFTNGP09.phx.gbl...
What could be the possible reasons (technical/non technical) of not
using lots of static functions or variables in a program keeping in mind
that Framework by itself has tons of static functions and variables?



Feb 9 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Bryan Parkoff | last post: by
12 posts views Thread by dual0 | last post: by
18 posts views Thread by Jack | last post: by
2 posts views Thread by Nagrik | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.