class A
{
public:
int& fn()
{
return m_number;
}
private:
int m_number;
};
const-correctness
Consider:
Should fn() be const? As you can see, it doesn't modify the object itself, but it returns a reference to an internal variable which allows the object to be changed externally. If fn() is marked const, then the code will not compile unless m_number is marked mutable, which leads me to guess that fn() should be left not const.
You should have two versions, a const & a non-const one.
Assuming you want to keep exposing your guts like that.
Assuming you want to keep exposing your guts like that.
struct Blah{ int& fn() {return m_number;} const int& fn() const {return m_number;}};
Quote:Original post by mattdclass A{public: const int& fn() const { return m_number; }private: int m_number;};
?
Not quite. The reference needs to be not const.
Quote:Original post by Shannon Barber
You should have two versions, a const & a non-const one.
Assuming you want to keep exposing your guts like that.
*** Source Snippet Removed ***
That is a good idea! Thanks. As for exposing my tender insides, the particular function I need this for has a good reason for doing so [smile].
class A{ public: int m_number;};
There's no point in making a member private if you're going to give any Tom, Dick or Harry who wants it full read or write access just by calling a public function. You gain nothing. Either make it a public member or encapsulate the data properly.
Enigma
Seconded. All you're doing is short-circuting the private protection, while offering none of the benefits proper Get/Set functions provide. Use getters and setters or make it public (please go with the first option).
I would question why you need to return a reference to a value type rather then just the value. Unless you are planning on changing the class member outside the class (which is kind of breaking encapsulation) you may as well just return the int. The int is probably smaller then the pointer to it (reference) anyway.
Quote:Original post by Enigmaclass A{ public: int m_number;};
There's no point in making a member private if you're going to give any Tom, Dick or Harry who wants it full read or write access just by calling a public function. You gain nothing. Either make it a public member or encapsulate the data properly.
Enigma
Quote:Original post by Nemesis2k2
Seconded. All you're doing is short-circuting the private protection, while offering none of the benefits proper Get/Set functions provide. Use getters and setters or make it public (please go with the first option).
Quote:Original post by paulecoyote
I would question why you need to return a reference to a value type rather then just the value. Unless you are planning on changing the class member outside the class (which is kind of breaking encapsulation) you may as well just return the int. The int is probably smaller then the pointer to it (reference) anyway.
This is for a WorldManager class that I posted about a few days ago. The thing I need to return (a list of GameObjects) is not stored internally as just a list of GameObjects. Rather, they're stored inside a map because each type of GameObject list is associated with a std::string identifier. So, if I simply make the map public then the external code has to deal with grabbing the iterator out and using find() and whatnot. Having an accessor function that yanks out the list directly simplifies things.
Also, if the internal map is exposed people could do things like use std::map's operator[] and inadverdently create new elements which would be bad.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement