Unity Opinions: Public const references to private members (c++)

This topic is 4501 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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?

Share on other sites
What do you do if the private member changes?

EDIT: Oh, nevermind.

Share on other sites
Quote:
 Original post by BeanDogAnyway, 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!

Share on other sites
Quote:
 Original post by Drew_BentonThe 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.

Share on other sites
Quote:
 Original post by FrunyAnd 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.

Share on other sites
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 ().

Share on other sites
Quote:
Original post by Fruny
Quote:
 Original post by Drew_BentonThe 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.)

1. 1
2. 2
3. 3
Rutin
17
4. 4
5. 5

• 10
• 14
• 30
• 13
• 11
• Forum Statistics

• Total Topics
631788
• Total Posts
3002355
×