Quote:You can write them yourself, if you dig deep in Software Engineering I think I posted the syntax of them all about two years ago.
But can you implement them with zero overheads (when compared to getters/setters)?
Worth Get() and Set() in games ?
But can you implement them with zero overheads (when compared to getters/setters)?
Yes if your get/set methods are both the trivial case and are inlined then there is no overhead to using a property.
Some people prefer not to use them because of side-effects (should accessing or setting a variable really make something else happen?), but I don't find that a problem unless I have poorly designed properties. IE: resist the urge to make all of your functions properties or something silly like that.
And example: A typical Windows form class could have a "Visible" property whose setter also called Show() and Hide()-type functionality on the window when changed. This is a smart thing to do, as it becomes very transparent to the caller, and you can also add code to make sure you only call the functions if the visability changes etc.
However if you tried to make a "Paint" property instead of a "Paint()" function, it's going to be extremely confusing. Sure this is an exaggerated example, but I've seen very poorly conceived properties before.
Sure MSVC++6 did have properties, but none nearly as flexable as those in 2005 - they are part of the language extensions that Microsoft is making (some pretty important ones), very much so that VC++ works well with the .NET architecture. For example, you can simply put:
property int Field;
And that will evaluate to a integer backing store with a property containing default get/set functions. Later you could change this and implement your own functions and not need to change any code anywhere. Basically they have a much cleaner syntax now, somewhat similar to Borland's.
As a general guideline, I'd say not to use a property unless you have a very well-defined backing-store (ie. a private/protected field directly associated with the property) and almost always setting that property should change the backing store and getting that property immediately following should return the new value. Yes there are exceptions (especially to the second rule), but if you stick to these you probably won't have trouble with weird side-effects. I generally only use properties as with my "Visible" example above: to make an API call or something that actually executes the instruction while changing the backing state variable.
I could easily see this done with Joystick properties for example (I mean who honestly enjoys the fun with "Device::SetProperty"?), and it would produce a much cleaner and easier-to-use interface.
Some people prefer not to use them because of side-effects (should accessing or setting a variable really make something else happen?), but I don't find that a problem unless I have poorly designed properties. IE: resist the urge to make all of your functions properties or something silly like that.
And example: A typical Windows form class could have a "Visible" property whose setter also called Show() and Hide()-type functionality on the window when changed. This is a smart thing to do, as it becomes very transparent to the caller, and you can also add code to make sure you only call the functions if the visability changes etc.
However if you tried to make a "Paint" property instead of a "Paint()" function, it's going to be extremely confusing. Sure this is an exaggerated example, but I've seen very poorly conceived properties before.
Sure MSVC++6 did have properties, but none nearly as flexable as those in 2005 - they are part of the language extensions that Microsoft is making (some pretty important ones), very much so that VC++ works well with the .NET architecture. For example, you can simply put:
property int Field;
And that will evaluate to a integer backing store with a property containing default get/set functions. Later you could change this and implement your own functions and not need to change any code anywhere. Basically they have a much cleaner syntax now, somewhat similar to Borland's.
As a general guideline, I'd say not to use a property unless you have a very well-defined backing-store (ie. a private/protected field directly associated with the property) and almost always setting that property should change the backing store and getting that property immediately following should return the new value. Yes there are exceptions (especially to the second rule), but if you stick to these you probably won't have trouble with weird side-effects. I generally only use properties as with my "Visible" example above: to make an API call or something that actually executes the instruction while changing the backing state variable.
I could easily see this done with Joystick properties for example (I mean who honestly enjoys the fun with "Device::SetProperty"?), and it would produce a much cleaner and easier-to-use interface.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
