• 13
• 18
• 19
• 27
• 10

[.net] [C#] Small get/set problem

This topic is 4345 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I'm currently trying to learn C#, but I've run into a problem with the get/set functionality.
        public KernelState State()
{
get
{
return _state;
}

set
{
_state = value;
}
}


Give me these errors, just after the get or set:
Error	1	; expected
Error	2	; expected
I appreciate the help. Thanks, storage.

Share on other sites
The problem is the parentheses

public KernalState State () should be:

public KernalState State
{
get
{
return _state;
}

set
{
_state = value;
}
}

Share on other sites
Thank you a lot! :)

I really appreciate it. Now I'm back to porting my engine to C#!

Share on other sites
if the property Stateis modifies _state unchecked, and without any side effects (no event is triggered, no value checking, etc), then why use it? Name _state as State and no need of the get/set property

Share on other sites
With the way you are doing things you might as well make _state public. Using it the way you did exposes it with out any protection. You should really verfy the value when you set it. Put in some error checking to make sure the value that you are setting is a valid value.

theTroll

Share on other sites
Quote:
 Original post by orbanoif the property Stateis modifies _state unchecked, and without any side effects (no event is triggered, no value checking, etc), then why use it? Name _state as State and no need of the get/set property

You can't have fields in an interface.

Share on other sites
I never use public fields these days. With code snippets it's so quick to insert the Property anyway, and your code'll be primed for proper serialization, PropertyGrids, Attributes, conditional breakpoints when the value changes etc.

Share on other sites
The reason that you use properties is the hide the internal data and to make sure that the data is valid. Just to use them becuase you can is a waste of time.

theTroll

Share on other sites
It does contain some useful semantics to use a public field instead of a property (you know it's not going to trig any code), but "empty" properties are very rare in my code. I always have to go back and change it to a property if I start out with a field, so prop<tab><tab> has become my default lately.

But how much slower is it actually in execution? Empty properties that is. I would've imagined some compiler optimizations would pretty much remove the difference.

Share on other sites
Quote:
 Original post by TheTrollThe reason that you use properties is the hide the internal data and to make sure that the data is valid. Just to use them becuase you can is a waste of time. theTroll

and full requirements analysis before implementation is impossible. changing requirements may dictate increased functionallity in the property. initially implementing access to the field as a property simplifies the later change. Besides, the compiler inlines simple properties like that anyway. You lose nothing in runtime and gain in refactoring time.