Well, that can lead to an argument.. but here's an example of when setters are good:
let's say you want to redisplay the screen every time coordinates of the player change.
you can make the setter do that as the coordinates change instead of doing multiple lines, you can call one function each time.
Also, just think if your display can change, or if you want boundaries and limits on the data than can be in there, you can do checks all within the function.
Getter/setters and constants
Author
Mikeman, awesome, but that does in no way help me with getters/setters.
Why would I make the getters return constants, or even do the const thing?
I just don't get it.
Maybe I have an idea - is it because getters arent used to make things constant, but used for more complicated stuff as I explained, and the const thing is the best way to handle it? argh im lost ;(
Why would I make the getters return constants, or even do the const thing?
I just don't get it.
Maybe I have an idea - is it because getters arent used to make things constant, but used for more complicated stuff as I explained, and the const thing is the best way to handle it? argh im lost ;(
Quote:
Why would I make the getters return constants, or even do the const thing?
First things first. Why would you make a function return constants? Basically, 99,9% of the time it's useless, since noone attempts to modify the return value of a function. Most of the times you don't write things like "foo()=42". In some cases it might mean something, but that does not concern us here.
Why would you want to define constant member functions? Consider the following class:
class Foo{private: int _x;public: Foo(int x):_x(x){} void SetX(int x){_x=x;} int GetX()const{return _x;} }int main(){ const Foo foo(0);}Now, you can't call "foo.SetX(42)". foo is a constant object, and SetX modifies the object. But you want to be able to call "foo.GetX", because GetX is a read-only function. That's why you do "the const thing". To tell the compiler it's legal to call GetX() upon a constant object.
Quote:slight hijack: when is a good time to use getters/setters? normally the way I used to use them, it seemed better make everything public.
IMO you should try to avoid having either as much as possible by specifying Actions/Behaviors instead, however, I believe that when you do legitimatly require them any thing with a getter and a setter where neither of them perform additional actions should be made public.
Author
Ah! Much better, thank you sooo much ;)
Now, I need to know this:
How taxing is it to have all getter/setters regardless of if they do anything extra rather than simple having variables public?
For instance, would a commercial game concerned with speed make getter/setters for everything, or for only stuff that benefit?
Now, I need to know this:
How taxing is it to have all getter/setters regardless of if they do anything extra rather than simple having variables public?
For instance, would a commercial game concerned with speed make getter/setters for everything, or for only stuff that benefit?
Quote:Why would I make the getters return constants, or even do the const thing?
I'm not sure if I fully understand what it is you're trying to ask, but as far as WHY a "getter" would return a constant goes... for the case you mentioned:
const int getX();
...or whatever. I can't think of a good reason for doing this, really. There may be one--who knows.
But imagine if you had a member function that returned a pointer to a variable that was inside of some class:
int* SomeClass::getX() { return this->X; }
SomeClass's X variable may be (read: is probably) private, but suddenly the calling function has access to it! The program could then go on to modify X to be some invalid or unexpected number, and terrible, terrible things could happen. If you wrote
const int* SomeClass::getX() { return this->X; }
then *poof*, your value can't be modified.
Having said all of that: don't do this. When your object is destroyed, there's a strong possibility that you'll leave a dangling pointer, as your member function getX returned a pointer to some space that is no longer allocated (or worse, has been reallocated for something else).
I believe this comes from "Effective C++", which is a great book that you should check out, if you haven't already:
http://www.awprofessional.com/content/images/0201924889/items/item21.html
Quote:For instance, would a commercial game concerned with speed make getter/setters for everything, or for only stuff that benefit?
I'm very inexperienced, but I don't think I've seen too many "getter/setters" in the code I've looked at--maybe there are a ton that I just haven't seen. I dunno. But from my (again, inexperienced) guess, you can just inline these trivial get/set functions. This way your run-time wouldn't suffer, and if you figured out that you need a whole lot of validity checking in a get/set function later on, you can just make the necessary changes to the function without having to change obj.X to obj.getX() all over the place in your code...
Firstly a well designed commercial game would only have a minimum of Get/Set/public's and would instead rely on the objects performing actions/behaviours but from a purly theoretical point of veiw using get/setters's would have a minimum to zero impact as the compiler (provided you let it) will inline the functions as necessary producing identicle code to using public variables.
Secondly even the most speed obsesed game would pick the option that gives the most benefits from a development/design perspective and then as necessary (as profiling indicates) refactor to use an alternative more efficient method (which wouldnt be required for Get/Setter's as IMO (ignoring pathalogical cases) they will never be a performance bottleneck.
Edit:
This is slightly of topic but it is posible to use obj.X initially then add heaps of validity checking without having to change all obj.X's to obj.getX()'s
Also the op, this thread although slightly advanced has a really good discussion of the merits/downsides of get/setter's, although a warning it gets a bit flamish towards the end.
Secondly even the most speed obsesed game would pick the option that gives the most benefits from a development/design perspective and then as necessary (as profiling indicates) refactor to use an alternative more efficient method (which wouldnt be required for Get/Setter's as IMO (ignoring pathalogical cases) they will never be a performance bottleneck.
Edit:
Quote:you can just make the necessary changes to the function without having to change obj.X to obj.getX() all over the place in your code...
This is slightly of topic but it is posible to use obj.X initially then add heaps of validity checking without having to change all obj.X's to obj.getX()'s
Also the op, this thread although slightly advanced has a really good discussion of the merits/downsides of get/setter's, although a warning it gets a bit flamish towards the end.
Quote:Original post by mikemanIt is of course quite uncommon because it is quite a bother to add the extra 'const', but actually it can be very useful. e.g:Quote:
Why would I make the getters return constants, or even do the const thing?
First things first. Why would you make a function return constants? Basically, 99,9% of the time it's useless, since noone attempts to modify the return value of a function. Most of the times you don't write things like "foo()=42". In some cases it might mean something, but that does not concern us here.
if (foo()=42) { ...}You learn something new everyday huh!
Quote:Original post by iMalcQuote:Original post by mikemanIt is of course quite uncommon because it is quite a bother to add the extra 'const', but actually it can be very useful. e.g:Quote:
Why would I make the getters return constants, or even do the const thing?
First things first. Why would you make a function return constants? Basically, 99,9% of the time it's useless, since noone attempts to modify the return value of a function. Most of the times you don't write things like "foo()=42". In some cases it might mean something, but that does not concern us here.That gives no error. But chances are you meant to use ==. If foo returns a const you are alerted to your mistake![cool]if (foo()=42) { ...}
You learn something new everyday huh!
Hadn't thought of that! Although in this case you could just learn to write "if (42==foo())" to achieve the same effect. Either way, as you said, I haven't seen anyone adding a "const" to each function just to avoid those potential mistakes.
when writing if statements I find its usually better to write the constant on the left hand side, that way if you do accidentally use the assignment operator '=' as opposed to the comparison operator '==' it will throw up a compiler error
eg..
if ( myNumber = 42 ) //this will compile
{
}
if ( 42 = myNumber ) // this would not compile as your trying to give 42 myNumber
{
}
therefore
if ( 42 == myNumber )
{
}
if ( NULL == myPointer )
{
}
etc etc..
eg..
if ( myNumber = 42 ) //this will compile
{
}
if ( 42 = myNumber ) // this would not compile as your trying to give 42 myNumber
{
}
therefore
if ( 42 == myNumber )
{
}
if ( NULL == myPointer )
{
}
etc etc..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
