Worth Get() and Set() in games ?
Author
I always have this problem. Is it worth using set and get for setting and getting class members in games ? Or put everything to public or friend. I mean if i call 1000 get and set in a frame(30-60 in a sec), how many cpu time i waste ? Please help me to decide, is it worth to do nice class hierarchy ?
If you're using Get() and Set() many times per frame, your code isn't very modular to begin with.
For objects that are 'just data', where the contents of the data have no impact on things (they're basically c-style structs), it does not matter if your variables are public. I usually just declare these objects as structs anyway.
There aren't that many things I use a Get() / Set() paradigm for -- i certainly do it anytime data needs to be validated, or when it can be used for clarity. It's almost universally the case that multiple get/set calls are being made when:
1.) The object doing the getting / setting should actually be the object controlling the data.
2.) The object that is being called should be performing the functionality itself.
Anyway, the overhead is usually nothing, since most compilers will inline stuff like:
For objects that are 'just data', where the contents of the data have no impact on things (they're basically c-style structs), it does not matter if your variables are public. I usually just declare these objects as structs anyway.
There aren't that many things I use a Get() / Set() paradigm for -- i certainly do it anytime data needs to be validated, or when it can be used for clarity. It's almost universally the case that multiple get/set calls are being made when:
1.) The object doing the getting / setting should actually be the object controlling the data.
2.) The object that is being called should be performing the functionality itself.
Anyway, the overhead is usually nothing, since most compilers will inline stuff like:
Vec GetPostition(){ return m_Position;}
This is one feature that C++ is missing that other languags have so nicely: properties that can remap the ".foo=" and "= .foo " statements into functions. Be they Python properties/getsets or VB properties or whatever, its a very handy mechanism, as it means forward-compatibility of just using =. If your interface changes and simple assignment is no longer appropriate, then no problem.
Still, the time loss of get() and set() should be negligable unless its your innermost loop, like some sort of render tree. In places like that I try to avoid oop altogether in favour of more direct approaches.
Still, the time loss of get() and set() should be negligable unless its your innermost loop, like some sort of render tree. In places like that I try to avoid oop altogether in favour of more direct approaches.
our coding standards have us use:
class someClass {
private:
bool variableName_;
public:
bool variableName() { return variableName; };
void variableName( bool boolIn ) { variableName = boolIn; };
}
obviously where "variableName_" is the name of your variable, and "boolIn" would be a more descriptively named variable.
In answer to your question, if a program is tiny, like 10 files and maybe 4 or 5 classes tops then making everything public should be fine, if it's anything over that then it's worth making things use a public interface like get() and set().
Having said that, you should have more generic methods that serve a specific purpose and not really allow people to be setting the value of variables inside a class directly.
In addition to that (sorry i'm blabbing on but i'm on a role now!) simple classes such as "vector" classes are often an exception to that rule as you want direct access to the variables so accessor functions are sometimes a bit of an overkill :)
hope that helps.
ACopland
class someClass {
private:
bool variableName_;
public:
bool variableName() { return variableName; };
void variableName( bool boolIn ) { variableName = boolIn; };
}
obviously where "variableName_" is the name of your variable, and "boolIn" would be a more descriptively named variable.
In answer to your question, if a program is tiny, like 10 files and maybe 4 or 5 classes tops then making everything public should be fine, if it's anything over that then it's worth making things use a public interface like get() and set().
Having said that, you should have more generic methods that serve a specific purpose and not really allow people to be setting the value of variables inside a class directly.
In addition to that (sorry i'm blabbing on but i'm on a role now!) simple classes such as "vector" classes are often an exception to that rule as you want direct access to the variables so accessor functions are sometimes a bit of an overkill :)
hope that helps.
ACopland
If you have a good compiler it will either inline the Get / Set statements, or if you code Get / Set statements in the way it's most common (you but the definition direclty in the definition of your class) then most compilers will inline it anyway, so, no there's no loss of the in using Get/Set statements even in your innermost loop.
Further on, the added type safety you get with using the Get/Set would make it worth to lose a few instruction over ( even though you don't )
Further on, the added type safety you get with using the Get/Set would make it worth to lose a few instruction over ( even though you don't )
doh!
that should have been:
class someClass {
private:
bool variableName_;
public:
bool variableName() { return variableName_; };
void variableName( bool boolIn ) { variableName_ = boolIn; };
}
thats what i get for posting when at work! :)
ACopland
that should have been:
class someClass {
private:
bool variableName_;
public:
bool variableName() { return variableName_; };
void variableName( bool boolIn ) { variableName_ = boolIn; };
}
thats what i get for posting when at work! :)
ACopland
First up, if there inlined, there should in theory be no extra hit.
Also with get/set funcs it would be easier to catch rogue code messing with your members when it should be. In that all code that alters the value must go through the set func(s).
Your get funcs can also be defined as const funcs:
int getFoo() const { return m_Foo; }
Which can prevent other code inadvertently changing your members. and just leads to much more stable and bullet proof code.
Another reason as I found out recently for using get/set funcs was how it makes changing the class a lot easier. My example was a big old class with lots of bool stored as chars and enum values in ints. We were short of memory, so we figured it would be good to bit pack it all.
Couldn't use the old:
class Foo {
mBar : 4; // fit into 4 bits
};
syntax as the struct was being written to a file to be loaded on another platform with a different compiler (can't guarentee it would pack the same across platforms/compilers).
So I had to do my own set/get functions for packing/unpacking the bits.
Then of course every reference to the old char & int members had to be changed... great. Had get/set funcs been used from the start, it would have been a lot less hassle.
If you have a class that's being exported from a dll, get/set funcs are essential to hide the implementation so you can easily change it without screwing up any client apps using the dll.
And there's probably loads more reasons to use get/set funcs. Eitherway the overhead is tiny or non existant, compared with the gains for using them.
Also with get/set funcs it would be easier to catch rogue code messing with your members when it should be. In that all code that alters the value must go through the set func(s).
Your get funcs can also be defined as const funcs:
int getFoo() const { return m_Foo; }
Which can prevent other code inadvertently changing your members. and just leads to much more stable and bullet proof code.
Another reason as I found out recently for using get/set funcs was how it makes changing the class a lot easier. My example was a big old class with lots of bool stored as chars and enum values in ints. We were short of memory, so we figured it would be good to bit pack it all.
Couldn't use the old:
class Foo {
mBar : 4; // fit into 4 bits
};
syntax as the struct was being written to a file to be loaded on another platform with a different compiler (can't guarentee it would pack the same across platforms/compilers).
So I had to do my own set/get functions for packing/unpacking the bits.
Then of course every reference to the old char & int members had to be changed... great. Had get/set funcs been used from the start, it would have been a lot less hassle.
If you have a class that's being exported from a dll, get/set funcs are essential to hide the implementation so you can easily change it without screwing up any client apps using the dll.
And there's probably loads more reasons to use get/set funcs. Eitherway the overhead is tiny or non existant, compared with the gains for using them.
Quote:Original post by Anonymous Poster
our coding standards have us use:
class someClass {
private:
bool variableName_;
public:
bool variableName() { return variableName_; };
void variableName( bool boolIn ) { variableName_ = boolIn; };
}
ACopland
I'm putting this in my "Good Coding Standards" doc. Beats getVar()/setVar().
Quote:Original post by Anonymous Poster
bool variableName() { return variableName_; };
Hmm... Just nit-picking, but it would be better as a const
member functions. Also, the last semi-colon is unnecessary.
bool variableName() const { return variableName_; }Quote:Original post by Etnu
1.) The object doing the getting / setting should actually be the object controlling the data.
2.) The object that is being called should be performing the functionality itself.
I hope people didn't miss this.
Either the data is on the wrong class.
Or the functionality is on the wrong class.
If, in particular, you have lots of get and set functions which use builtin types then you probably haven't abstracted your design enough. Build up useful types which you pass around rather than passing ints and doubles which can't have any functionality and don't communicate purpose.
For example you might have an integer class member representing time in seconds since 01/01/1970. To increase the time by a week you might say:
int oldTime = obj.getTime();then calculate a week in seconds and say
obj.setTime(oldTime + week);It could be better to wrap the integer in a class called Time which has functions to add times together, increase by a day, week, year etc.
The original class could then have Time as a member. And you might have a function:
obj.moveWeekForward();
You wouldn't be passing around integers. You wouldn't even get to touch the Time class. Any calculation of what a week is in seconds is encapsulated in the Time class.
You can keep doing this. So the function which calls moveWeekForward on the obj might really belong on the obj class itself, and the moveWeekForward might not need to be a public function or even necessary at all, etc.
This isn't to say getters and setters are wrong. But they can indicate problems with your design.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
