Back to General and Gameplay Programming

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

General and Gameplay Programming Programming

Started by storage April 24, 2006 07:34 AM

30 comments, last by bL0wF1sH 17 years, 12 months ago

storage

175

Author

April 24, 2006 07:34 AM

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.

TMP72

138

April 24, 2006 07:43 AM

The problem is the parentheses

public KernalState State () should be:

public KernalState State
{
get
{
return _state;
}

set
{
_state = value;
}
}

storage

175

Author

April 24, 2006 07:51 AM

Thank you a lot! :)

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

Adios!

orbano

130

April 24, 2006 08:45 AM

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

"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin

TheTroll

883

April 24, 2006 09:57 AM

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

Arild Fines

968

April 24, 2006 10:22 AM

Quote:Original post by orbano
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

You can't have fields in an interface.

--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]

Jonas B

100

April 24, 2006 12:18 PM

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.

TheTroll

883

April 24, 2006 12:47 PM

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

Jonas B

100

April 24, 2006 02:29 PM

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.

capn_midnight

1,708

April 24, 2006 04:10 PM

Quote:Original post by TheTroll
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

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.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines