class Man
{
int age;
public:
void SetAge(int val);
int GetAge() const;
};
class Man
{
int age;
public:
void Age(int val);
int Age() const;
};
Which you do YOU prefer? (about Set/Get in C++)
Author
Hey just wanna get some opinions:
Which do you prefer:
or
Man m;
m.Age(100);
cout << m.Age();/...
[Edited by - sheep19 on May 27, 2010 2:32:36 PM]
I think this is worth a read (whether you agree with the conclusion or not - it's food for thought): C++ killed the get & set accessors
Author
Quote:Original post by DevFred
Why does the getter have an int parameter?
Fixed.
--
Great article! ;)
If you don't have to do something to the variable when you get/set, what's wrong with:
?
Just seems a little OTT for me, unless there's a reason to make it private.
Then again, I'm not exactly great at this stuff. :P
man.age = 100;std::cout << man.age << std::endl;?
Just seems a little OTT for me, unless there's a reason to make it private.
Then again, I'm not exactly great at this stuff. :P
Author
Quote:Original post by The Communist Duck
If you don't have to do something to the variable when you get/set, what's wrong with:man.age = 100;std::cout << man.age << std::endl;
?
Just seems a little OTT for me, unless there's a reason to make it private.
Then again, I'm not exactly great at this stuff. :P
Let's say I have.
void Man::Age(int val){if(val < 0) throw std::out_of_bounds("Age can't be negative.");age = val;}
I do GetAge/SetAge but I did read somethign with doing just "Age" for a getter and "SetAge" for the setter which I might adopt. Shame we can't have c# style as I like that alot.
I follow a very simple principle: functions (potentially) do interesting stuff, so they should be verbs. Get/Set it is.
-------------
EDIT:
For example, consider the following class declaration:
Now, say I find this code somewhere (I didn't write it, and I neither know nor wish to be bothered with the implementation details of Person):
This is ambiguous -- did the class designer intend for age(N) to mean "set age to N" or did s/he mean "advance age by N"? The problem is that age is both a verb and a noun. By contrast, a get/set-prefixed function's purpose is unambiguous.
-------------
EDIT:
For example, consider the following class declaration:
class Person { int age;public: void age(int n); int age() const;};Now, say I find this code somewhere (I didn't write it, and I neither know nor wish to be bothered with the implementation details of Person):
void doSomethingCool(Person& person){ person.age(42);}This is ambiguous -- did the class designer intend for age(N) to mean "set age to N" or did s/he mean "advance age by N"? The problem is that age is both a verb and a noun. By contrast, a get/set-prefixed function's purpose is unambiguous.
I'm sorry for hi-jacking this thread, but reading the article and the article referred in that article [smile] left me thinking.
In the end of A simple meta-accessor there is:
I do not see why you should put the const inside the template argument.
The only difference I get is that when using 'Accessor<const int>' the compiler generates a more obscure error than when using 'const Accessor<int>'. That error is of course produced if you try to modify the int inside the Accessor.
Can someone enlighten me?
In the end of A simple meta-accessor there is:
Quote:
And finally, for const members make the type inside Accessors const rather than the Accessors object. I'll leave it to you to work out reasons for this.
I do not see why you should put the const inside the template argument.
The only difference I get is that when using 'Accessor<const int>' the compiler generates a more obscure error than when using 'const Accessor<int>'. That error is of course produced if you try to modify the int inside the Accessor.
Can someone enlighten me?
Quote:Original post by Windryder
This is ambiguous -- did the class designer intend for age(N) to mean "set age to N" or did s/he mean "advance age by N"? The problem is that age is both a verb and a noun. By contrast, a get/set-prefixed function's purpose is unambiguous.
And generally excessive. Age and Age(42) is a well known idiom, and as long as you're consistent within your project there will generally be no ambiguity.
But like many other things, consistency is key. Pick one. Go with it. Stick with it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
