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.

If you use that method, you cannot change the implementation to anything other than an int value. So if in the future you need to compute the value on the fly instead of saving it in the class instance, then you must change the interface to use a get method instead of the reference and update all that code that uses the class. That is a big reason why you use the get method in the first place.

I've never seen this approach before either, although I guess it's one way of skinning the cat. Personally, I consider there are too many circumstances where I'd want to evolve from something like this to using a getter, and this approach makes more work retrofitting that, so I'd probably just go for the getter upfront.

Another issue with the approach (other than the space issue and supplying an assignment operator) is that it is also necessary to supply a copy constructor.

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

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.

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.

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

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.

I don't know, for toy programs (which is the kind of program I think we're talking about) the const reference doesn't seem so bad. And when you have data members on the heap it's not trouble to code a copy constructor or an assignment operator, because in that case you need those things anyway. That's when I use it, but then I don't work for anyone.

In C++ applications used by consumers I doubt that get/set functions are used a lot. When they are there is a good reason for it. There are plenty of better ways to make an interface.

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.

I don't necessarily agree that's a disaster waiting to happen (almost everything in C++, or any other programming language can be used well or misused), but the sort of concerns you raise are why I described using an operator int() as having it's share of trade-offs.