Using set and get in C Sharp

[Complete]

What is the point of using set and get in C Sharp?

It seems variables are used differently in this language than in C++.

For some reason, you have to have a static variable defined like this:

public static uint Somenum

{

set { m_somenum = value; }

get { return m_somenum; }

}

and prior to this declaration, you need to have this:

public uint m_sumenum;

This seems to be the only way to expose a member of a class to other classes in C#.

The problem is that I seem to be doing this improperly because I get a compile error:

An object reference is required for the non-static field, metod, or property '.......m_somenum"

I think I see the problem. The problem is that I cannot use a static varable like this.

So you have to instantiate the class in order to set these members of the class.

So how would you do the equivalent of a global class in C Sharp?

Would I do it something like this:

public clase SomeClass

{

SomeClass someclass = new SomeClass();

public static uint Somenum

{

set { m_somenum = value; }

get { return m_somenum; }

}

}

Or perhaps this "new" needs to be outside of the class in order to work. So my next question is this. How and where would that command be such that it the internal set methods could be accessed by the other classes in the code?

[Andre S. Veteran]

The reason the compiler complains is because you are trying to access an instance variable inside a static method. Properties are synctatic sugar for getters and setters, so you should consider them as methods. So, you declare your property as static, but inside the property you try to access m_somenum which is not declared static; that is the problem. You need to either have both the property and its underlying variable static, or none.

If you want "global variables" in C Sharp, you can declare a class containing public static variables, in the global namespace, that is, not in any particular namespace.

[David Scaife]

(Beaten to it, heh)

The problem you're having with your static declarations is that while your accessor/mutator is static, the variable it is accessing is not. In your example, the member m_somenum would need to be static as well. Besides that, I think you have the wrong idea about how they can be used.

What is the point of it? The idea behind these get/set bits of code is to reduce the amount of code needed to achieve information hiding. For example, I'll make a comparison between equivalent code in Java and C#:

/* Java */
class Example
{
  private int _blah;

  public int GetBlah () 
  {
	return _blah;
  }

  public void SetBlah (int newval) 
  {
	/* Maybe do some range checking here */ 
	_blah = newval;
  }
}

/* ...now in some method: */
Example e = new Example();
e.SetBlah(3);
System.out.println("The value is " + e.GetBlah());

/* C# */
class Example
{
  private int _blah;

  public int Blah
  {
	get { return _blah; }
	set 
	{ 
	  /* Maybe do some range checking here */ 
	  _blah = value; 
	}
  }
}

/* Now in some method... */
Example e = new Example();
e.Blah = 3;
Console.WriteLine("The value is " + e.Blah);

If you really don't want to, you don't have to use these accessors/mutators (I think they're referred to as Properties); you could just declare Blah as a public int and be done with it, but that's dangerous.

[Bazenga]

If you really don't want to, you don't have to use these accessors/mutators (I think they're referred to as Properties); you could just declare Blah as a public int and be done with it, but that's dangerous.

Where is the danger? could you explain please? Are you talking about this:

class Example
{
  private int _blah;

  public int Blah
  {
	get { return _blah; }
	set
	{
	  /* Maybe do some range checking here */
	  _blah = value;
	}
  }
}

or this :

public int Test { get; set; }

[Linkinfamous]

He means doing this:

class Example
{
public int Test;
}

is dangerous.

[Mr. Bean]

To supplement what David said about reducing the amount of code needed to accomplish the same thing, .NET 3.0 introduces support for automatic getters and setters:

public int Blah {get;set;}

[David Scaife]

Where is the danger? could you explain please?

Sorry, I should have elaborated.

As MioTheGreat said, the danger lies in giving variables public visibility. It is dangerous because it violates the principle of information hiding, and removes your ability to perform any sensible kind of validation when another peice of code changes the value of the variable. Even if you're not doing any validation and any value would suffice for a particular variable, it'd be a terrible habit to get into, whether it's C# or Java or any other object-oriented language you're programming in.

[JamesCherrill]

Where is the danger? could you explain please? Are you talking about this:

Previous posters are right about using setters for validation etc. In addition, it may be the case (now or later) that other things depend on the value of that variable. If everyone has direct access then you will never know when its value has been changed.

There's also a strong case for getters, because at some tine in the future you may want to change the internal representation of that data, or virtualise it, or defer initialisation until it's needed, all of which are easy if there's a getter, impossible if the world has direct access to the variable.

Maybe you remember the "year 2k" problem, when companies spent millions changing the internal representation of dates and thus the code of every module that used a date. If those dates had been hidden behind getters the change would have not affected most modules, and thus been an order of magnitude easier.

Edited January 19, 2009 by JamesCherrill

[Antaris Veteran]

public int Test { get; set; }

Used this way, this is an example of C#'s automatic getters and setters. Realistically you are not doing anything different, its just that the compiler generates the field responsible for this property:

public int Test { get; set; }

Will translate to:

[CompilerGenerated]
private int <Test>k__BackingField;

public int Test
{
	[CompilerGenerated]
	get
	{
		return this.<Test>k__BackingField;
	}
	[CompilerGenerated]
	set
	{
		this.<Test>k__BackingField = value;
	}
}

Well, in IL equivalent.

[Bazenga]

Owh, awesome. How did your knowledge so deep? I want to deepen my knowledge as well!!

[Antaris Veteran]

Lol, I just like tinkering about with stuff ;)

[Andre S. Veteran]

Owh, awesome. How did your knowledge so deep? I want to deepen my knowledge as well!!

You could open ILDASM and look at the IL generated. It's hard to read, but it's better than x86 assembly.

[sbauer]

You could open ILDASM and look at the IL generated. It's hard to read, but it's better than x86 assembly.

Or just download Reflector and decompile the code into IL, C# or VB.NET.

[Antaris Veteran]

Or just download Reflector and decompile the code into IL, C# or VB.NET.

If I could make love to software...I'd make love to Reflector :ninja: