Thread: read-only data members. A question of good practices

Code:

class myClass {
public:
    myClass(): val(0), value(val) {}
    myClass(int x): val(x), value(val) {}
    void set_value(int x) { val = x; }
private:
    int val;
public:
    const int &value;
};

The above is a minimalist example to illustrate my question...

Instead of coding getters for every data member, is the const reference considered a correct approach within the context of good programming practices under C++?

EDIT: I understand this forces me to overload the assignment operator. But still... is this a common practice?

No, it would not, because the user can't change val through the reference.

I've never seen it done, but I see no particular reason why you shouldn't do it, aside from the need for an assignment operator you mentioned, an additional pointer per instance (the reference must actually be stored), and the fact that it would probably confuse most programmers who initially come across it.
Come to think of it, the space issue is probably the reason why nobody does it. Imagine: on my AMD64, the reference makes each instance of the class go from 4 bytes to 12. That's quite a price to pay.

Originally Posted by grumpy

One other alternative to this, with it's own share of trade-offs, is supplying an operator int() for the class.

Sorry grumpy, but that's a disaster waiting to happen. First you lose all the information in the code that tells you when you're accessing int. Second your class becomes convertible to int and consequently bool.
so if anyone has this

Code:

class anotherClass
{
public:
    anotherClass(int);
};

myClass instantly becomes convertable to anotherClass, almost certainly not what you want.

Ok folks. Thanks for the information.

It seemed a good option when I first started thinking how could I get read-only data members that map to private members. It would alleviate me of the () operator and it seemed faster than incurring on a getter function call.

My Visual Basic legacy makes it very intuitive to access a data member directly obj.member, instead of obj.getter(). Private data members can be accessed directly for read-only purposes. It is just an habit I have to lose.

Thanks again.

Originally Posted by Mario F.

Ok folks. Thanks for the information.

It seemed a good option when I first started thinking how could I get read-only data members that map to private members. It would alleviate me of the () operator and it seemed faster than incurring on a getter function call.

My Visual Basic legacy makes it very intuitive to access a data member directly obj.member, instead of obj.getter(). Private data members can be accessed directly for read-only purposes. It is just an habit I have to lose.

Thanks again.

if you inline the getter function call, the speed penalty disappears.

Python and C# allow the concepts of Properties, which basically maps a public "variable" to a set/get pair, i.e

Code:

// C#
class aClass
{

   public string Name 
   {
      get 
      {
         Console.WriteLine("called get");
         return name; 
      }
      set 
      {
         Console.WriteLine("called get");
         name = value; // value is a special varialbe
      }
   }
}

I think this was in vb as well? Anyway it's quite a nice bit of syntactic sugar, and maintains encapsulation

Yes, that's the VB paradigm too. Get and Set are full blown code structures by their own right and can be selectively omitted in order to provide concepts like read-only data members and private data members. The syntax also allows for direct access.

if you inline the getter function call, the speed penalty disappears.

Yes. No doubt.