I aksed a few days ago about static methods and got some good answers that
were really useful.

Now I am not sure if about the use of static on members (variables) and
classes.

Can someone please give me some advice about static classes and members too?

Thanks

Doug

Gordon,

Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use them in
my opinion there were you are sure that you needs them endless times and
don't need more instances of them.

(Be aware that there is other behaviour for ASPNET applications than for
WindowForms applications about static, just because a windowforms is a
client while an ASPNET application is a middle tier)

However (not the later sentence), just my idea.

Cor

"gordon" <(E-Mail Removed)> schreef in bericht
news:44fabcd0$0$5105$(E-Mail Removed)...
>I aksed a few days ago about static methods and got some good answers that
>were really useful.
>
> Now I am not sure if about the use of static on members (variables) and
> classes.
>
> Can someone please give me some advice about static classes and members
> too?
>
> Thanks
>
> Doug
>

I'm not sure I'd put it quite as strongly as Cor... static members do
have their place... but if you have static fields [fields=class level
variables] on a class, then the biggest thing you need to consider is
thread safety - not a trivial subject.

Simple static "helper" functions that don't talk to static fields are
intrinsicly thread-safe, but as soon as fields are involved you need to
be aware that in a non-trivial app different threads may be using the
static class at once, so the impact needs to be understood...

Of course, if you *know* you aren't going to be using threading, then
OK ;-p

Jon Skeet has a very good article on threading - note it goes into many
pages...
http://www.yoda.arachsys.com/csharp/threads/

Marc

This doesn't make any sense. A static method doesn't keep any memory
occupied beyond the stack that is allocated when the call is made.

However, when the method exits, the memory for the stack is gone as
well.

Static fields are a different story, and yes, they will last as long as
the application domain lasts. However, saying that you shouldn't use them
is a premature optimization, since in reality, they might be pointing to an
object, and the size of the reference is not high. Even if the object is
big, instance members can reference large objects, and live for the life of
an app domain as well, depending on the use.

Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

In the end, the OP asked about static methods, not static fields.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)

"Cor Ligthert [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Gordon,
>
> Just as rule for yourself, if you *can* avoid them, than avoid them.
>
> They keep forever the memory occupied and therefore you should use them in
> my opinion there were you are sure that you needs them endless times and
> don't need more instances of them.
>
> (Be aware that there is other behaviour for ASPNET applications than for
> WindowForms applications about static, just because a windowforms is a
> client while an ASPNET application is a middle tier)
>
> However (not the later sentence), just my idea.
>
> Cor
>
> "gordon" <(E-Mail Removed)> schreef in bericht
> news:44fabcd0$0$5105$(E-Mail Removed)...
>>I aksed a few days ago about static methods and got some good answers that
>>were really useful.
>>
>> Now I am not sure if about the use of static on members (variables) and
>> classes.
>>
>> Can someone please give me some advice about static classes and members
>> too?
>>
>> Thanks
>>
>> Doug
>>
>
>

Did I write what you wrote?
>
> Also, ASP.NET does not treat static fields any differently. Static
> fields live for the life of the app domain, no more, no less. Granted,
> ASP.NET recylces app domains, and one has to be aware of that, but static
> fields have no say in that, it is the runtime of ASP.NET that determines
> that.
>
The behaviour of a windowforms program is different than an ASPNET
application, just because in a windowform program the client is the
application and in a aspnet application that it the genereated
HTML/Javascript page. Therefore the complete application behaves different.
A static method in a ASPNET application acts for the rest the same as in any
other C# application.

Static means fixed. In old non by the OS relocatable programs (C) it means
true fixed to a memory address. In more modern OS it means fixed to the
memory starting point where the program is located. In my idea can there
never been an other description for that otherwise the Static keyword is in
my idea wrong used.

However just my thought,

Cor

Cor,

Again, you are making a premature optimization. If the design calls for
a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.

--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)

"Cor Ligthert [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Did I write what you wrote?
>>
>> Also, ASP.NET does not treat static fields any differently. Static
>> fields live for the life of the app domain, no more, no less. Granted,
>> ASP.NET recylces app domains, and one has to be aware of that, but static
>> fields have no say in that, it is the runtime of ASP.NET that determines
>> that.
>>
> The behaviour of a windowforms program is different than an ASPNET
> application, just because in a windowform program the client is the
> application and in a aspnet application that it the genereated
> HTML/Javascript page. Therefore the complete application behaves
> different. A static method in a ASPNET application acts for the rest the
> same as in any other C# application.
>
> Static means fixed. In old non by the OS relocatable programs (C) it means
> true fixed to a memory address. In more modern OS it means fixed to the
> memory starting point where the program is located. In my idea can there
> never been an other description for that otherwise the Static keyword is
> in my idea wrong used.
>
> However just my thought,
>
> Cor
>

Nick,

It is great, but where is the intention from your current message different
from the first line in the one I started with?

Yours
> Again, you are making a premature optimization. If the design calls
> for a static member, then you should use a static member. An extra field
> reference isn't going to bring your app tumbling down.

Mine
>>Just as rule for yourself, if you *can* avoid them, than avoid them.

I did nowhere write that you *should* not use them.

Cor

Cor Ligthert [MVP] <(E-Mail Removed)> wrote:
> It is great, but where is the intention from your current message different
> from the first line in the one I started with?
>
> Yours
> > Again, you are making a premature optimization. If the design calls
> > for a static member, then you should use a static member. An extra field
> > reference isn't going to bring your app tumbling down.
>
> Mine
> >>Just as rule for yourself, if you *can* avoid them, than avoid them.
>
> I did nowhere write that you *should* not use them.

But you're suggesting that you should avoid them where possible - in
other words, that it's worth skewing the design in order to avoid them.
I, like Nicholas, disagree with that. If a static member is the natural
design, there's no need to avoid it.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jon,

Where is a static class or a whatever class a natural design.

I don't know if you believe in the great Englisman Darwin, otherwise have a
look in the Bibble both is about natural design. A static class is never for
me a Natural design as is not any class.

Both you are writing "an extra field reference isn't going to bring your app
tubling down"

I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that, therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to much
effort in that.

So I am curious in what context you place that sentence?

Cor

"Jon Skeet [C# MVP]" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Cor Ligthert [MVP] <(E-Mail Removed)> wrote:
>> It is great, but where is the intention from your current message
>> different
>> from the first line in the one I started with?
>>
>> Yours
>> > Again, you are making a premature optimization. If the design calls
>> > for a static member, then you should use a static member. An extra
>> > field
>> > reference isn't going to bring your app tumbling down.
>>
>> Mine
>> >>Just as rule for yourself, if you *can* avoid them, than avoid them.
>>
>> I did nowhere write that you *should* not use them.
>
> But you're suggesting that you should avoid them where possible - in
> other words, that it's worth skewing the design in order to avoid them.
> I, like Nicholas, disagree with that. If a static member is the natural
> design, there's no need to avoid it.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too

Cor Ligthert [MVP] <(E-Mail Removed)> wrote:
> Where is a static class or a whatever class a natural design.

Where utility methods are required, for starters. Besides, you didn't
originaly limit yourself to static classes, but to all static
variables.

At that point, you're preventing patterns such as the singleton pattern
(which does have disadvantages, but is appropriate sometimes).

> I don't know if you believe in the great Englisman Darwin, otherwise have a
> look in the Bibble both is about natural design. A static class is never for
> me a Natural design as is not any class.

What would you do with HttpUtility then, just as an example? All its
members are static, so it effectively could (and should) be a static
class. The fact that it's got a public constructor is a mistake,
basically.

How about the System.Math class?

> Both you are writing "an extra field reference isn't going to bring your app
> tubling down"

Actually, I never wrote that.

> I cannot place the context of this message, is this something Nick has
> stated in this thread.
>
> You should know that I would be the last one who would write that, therefore
> we have had to much discussions about by instance avoiding boxing. From
> which I write forever that you should try to avoid that but not put to much
> effort in that.

Again though - where the design naturally uses boxing, it's fine to use
boxing.

> So I am curious in what context you place that sentence?

You said to avoid static members where you *can* avoid them. You almost
always *can* avoid them - which means that by your standards, they
should virtually never be used.

Here's an example. Consider the Encoding class and its ASCII property.
That *could* create a new instance of ASCIIEncoding each time, instead
of caching it in a static variable. So one *can* avoid using a static
variable - and according to your logic, one therefore *should* avoid
it. Now, how is creating an instance of ASCIIEncoding every time
Encoding.ASCII is used actually a *good* idea? Do you like having lots
of instances of classes which effectively have no state?

Now, if you didn't actually mean your statement to be as strong as it
was, you shouldn't have made it that way. I can only go by what you've
actually written...

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too