class MyClass
{
private:
int m_iValue;
public:
const int &Value
// ...
};
MyClass::MyClass() : Value(m_iValue)
{
}
I've used this construct off and on, depending on my mood and the color of the moon. It saves you the trouble calling getter functions all the time for members that you only want publicly accessible for read access.
Anyway, it's valid C++, and I'm a bit fond of it. I just wonder what this community at large thinks of it. Anybody ever used it?
Opinions: Public const references to private members (c++)
What do you guys think about this kind of a design:
Quote:Original post by BeanDog
Anyway, it's valid C++, and I'm a bit fond of it. I just wonder what this community at large thinks of it. Anybody ever used it?
Never used or seen it before now, but it looks pretty interesting. I might have to consider messing with that design in the future when I get back to using C++. The only issue that I see with this design is that someone can "hack it". For example:
class MyClass{private: int m_iValue;public: const int &Value; // ... MyClass::MyClass();};MyClass::MyClass() : Value(m_iValue){ m_iValue = 0;}void main(){ //Manager<int, func> var; MyClass myC; int* temp = (int*)&myC.Value; (*temp) = 6; int val = myC.Value; // er, just so I could breakpoint on this line :) // myC.Value is 6 now instead of 0}
So if you have private members that someone else is using, then maybe a Get is the best way to keep it safe (thinking derived classes and libraries where someone doesn't have the original code). Good deal though, thanks for sharing!
Quote:Original post by Drew_Benton
The only issue that I see with this design is that someone can "hack it".
A const_cast makes it even easier. You should only worry about accidental misuse and error prevention. You can't guard against malice.
As for the trick itself, I just think it's a bit pointless here. You're increasing the size of the object just for the sake of saving typing a pair of parentheses.
#include <iostream>struct Foo { int i; };struct Bar { int i; const int& j; };int main(){ std::cout << sizeof(Foo) << ' ' << sizeof(Bar) << std::endl;}
And you're not even saving that much in member functions, since you end up having to write an assignment operator: references are not assignable.
All in all, it's more trouble than its worth if you don't have an otherwise compelling reason to have a member reference.
Quote:Original post by Fruny
And you're not even saving that much in member functions, since you end up having to write an assignment operator: references are not assignable.
I don't think it saves anything code wise. If anything it adds to the amount of code within a class, and certainly adds to the complexity.
I used to do this too a while back.. but a few problems: (covered quite well above)
1) Increases size, so I didn't want to use it for classes that are instances like thousand times.
2) It broke the automatic generation of assignment operators.
3) You still need to write the setter, this only covers the getter method.
4) over time I got confused which variable was const and which wasn't.
While I thought I'm being clever it kinda shot back at me because of 2). In the end I figured it would be better to just type the ().
1) Increases size, so I didn't want to use it for classes that are instances like thousand times.
2) It broke the automatic generation of assignment operators.
3) You still need to write the setter, this only covers the getter method.
4) over time I got confused which variable was const and which wasn't.
While I thought I'm being clever it kinda shot back at me because of 2). In the end I figured it would be better to just type the ().
Quote:Original post by FrunyQuote:Original post by Drew_Benton
The only issue that I see with this design is that someone can "hack it".
A const_cast makes it even easier. You should only worry about accidental misuse and error prevention. You can't guard against malice.
QFE. If you can't trust them not to do that (Drew's original example), you can't trust them not to just cast a pointer-to-the-base-object, add an offset, and cast it back, no matter the protection mechanism used. You could overload operator& and other such nasty effects, but fighting fire with fire like that in an uphill battle you will likely lose (for even that can be trumped with boost::addressof (see boost/utility.hpp documentation), and they're inventing even better idiots all the time.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement