Jump to content
  • Advertisement
Sign in to follow this  
BeanDog

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.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What do you guys think about this kind of a design:
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 this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
I was just thinking about this (having read-only values). Thanks for the share! [smile]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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 this post


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


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.)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!