Why new ?

  • Thread starter Thread starter GTi
  • Start date Start date
G

GTi

Maybe a very stupid question for an expert, but:

I have created a lib project in c# with some functions.
But how can I call this functions?

Functions libs:
namespace MyLib
{
class RegLib
{
public void WriteRegKey(string subKey, string name, string value)
{
RegistryKey key = Registry.LocalMachine.CreateSubKey(subKey);
key.SetValue(name, value, RegistryValueKind.String);
key.Close();
}
}
}


ref. files:

RegLib rl = new RegLib();
rl.WriteRegKey(...);


Why do I have to create a new RegLib() to call WriteRegKey?
How can I call this just by using:
RegLib.WriteRegKey(...);
 
GTi said:
Maybe a very stupid question for an expert, but:

I have created a lib project in c# with some functions.
But how can I call this functions?

Why do I have to create a new RegLib() to call WriteRegKey?
How can I call this just by using:
RegLib.WriteRegKey(...);

Your method is an instance method - it acts on an *instance* of the
class.

If you want to be able to call RegLib.WriteRegKey(...), just make it
static:
public static void WriteRegKey(string subKey, string name, string
value)
{
....
}

Jon
 
GTi said:
Maybe a very stupid question for an expert, but:

I have created a lib project in c# with some functions.
But how can I call this functions?

Functions libs:
namespace MyLib
{
class RegLib
{
public void WriteRegKey(string subKey, string name, string value)
{
RegistryKey key = Registry.LocalMachine.CreateSubKey(subKey);
key.SetValue(name, value, RegistryValueKind.String);
key.Close();
}
}
}


ref. files:

RegLib rl = new RegLib();
rl.WriteRegKey(...);

Why do I have to create a new RegLib() to call WriteRegKey?
How can I call this just by using:
RegLib.WriteRegKey(...);

You have defined your methods to be normal methods of a class, which
are called instance methods. So to use them, you first need to
instantiate the class to an object, then call the method on the object,
as the methods only live inside an instance of the class.

If you want to use them like RegLib.WriteRegKey(), you can define them
as static:


namespace MyLib
{
class RegLib
{
public static void WriteRegKey(string subKey, string name, string
value)
{
RegistryKey key = Registry.LocalMachine.CreateSubKey(subKey);
key.SetValue(name, value, RegistryValueKind.String);
key.Close();
}
}
}

and now you can do:
RegLib.WriteRegKey(....);

Keep in mind that static methods work on a single instance behind the
scenes. This means that local variables created INSIDE a method are
thread safe, but class wide variables (globals) aren't.

FB




--
 
Frans Bouma [C# MVP] wrote:

Keep in mind that static methods work on a single instance behind the
scenes.

No they don't - they don't work on *any* instance (of the class
involved). You may have meant that they work on a single instance of
Type, or something like that, but it's not terribly clear. One common
misconception (which I suspect you don't share, but which is worth
pointing out for the OP's sake) is that static variables are "shared
between all instances of the class". In fact, they are *independent* of
any instances of the class - meaning that you don't have to have any
instances of the class whatsoever in order to use them.

Jon
 
Jon said:
Frans Bouma [C# MVP] wrote:

Keep in mind that static methods work on a single instance behind
the scenes.

No they don't - they don't work on any instance (of the class
involved). You may have meant that they work on a single instance of
Type, or something like that, but it's not terribly clear. One common
misconception (which I suspect you don't share, but which is worth
pointing out for the OP's sake) is that static variables are "shared
between all instances of the class". In fact, they are independent of
any instances of the class - meaning that you don't have to have any
instances of the class whatsoever in order to use them.

Thanks for formulating it more clearly than I did :). I used the
instance metaphore to illustrate the concept of thread insafety.

FB

--
 
No they don't - they don't work on *any* instance (of the class

Since you are such a stickler for picking out the right words, I thought I
might, too, in jest, of course:)
is that static variables are "shared
between all instances of the class". In fact, they are *independent* of
any instances of the class - meaning that you don't have to have any
instances of the class whatsoever in order to use them

You say "shared between all **instances** of the class" and then you go on
to say
"*independent* of any **instances** of the class " and "you don't have to
have any **instances** of the class whatsoever in order to use them".

So many **instances** being used, all in the same context, I guess?:)

Regards

Jv

Jon Skeet said:
Frans Bouma [C# MVP] wrote:

Keep in mind that static methods work on a single instance behind the
scenes.

No they don't - they don't work on *any* instance (of the class
involved). You may have meant that they work on a single instance of
Type, or something like that, but it's not terribly clear. One common
misconception (which I suspect you don't share, but which is worth
pointing out for the OP's sake) is that static variables are "shared
between all instances of the class". In fact, they are *independent* of
any instances of the class - meaning that you don't have to have any
instances of the class whatsoever in order to use them.

Jon
 
Ravichandran J.V. said:
You say "shared between all **instances** of the class" and then you go on
to say
"*independent* of any **instances** of the class " and "you don't have to
have any **instances** of the class whatsoever in order to use them".

So many **instances** being used, all in the same context, I guess?:)

There don't have to be any instances used. Note that I was saying that
*other people* talked about static variables being "shared between all
instances of the class" - I was arguing *against* that point of view.
 
Thanks for the reply.

Jon Skeet said:
There don't have to be any instances used. Note that I was saying that
*other people* talked about static variables being "shared between all
instances of the class" - I was arguing *against* that point of view.
 
Back
Top