Returning references of private members = bad style?

Question

Hello, I came accross a strange thing in a huge code I have to use in my studies.
There it is possible, to get the address of a private member variable by a public function which returns a reference.
Now I'm wondering why one would even do that instead of just using usual getter/setter methods. Otherwise the variable could be made public in the first place...

For better understanding I coded a minimal example, see below.

Did anyone encounter similar stuff and/or knows in which case you want to have such a method?
Seems like bad smell to me... So I was surprised to see something like this in a sophisticated code/project.

https://code.sololearn.com/cB4or8SYK9Gm/?ref=app

Answer 1

First of all you are not returning a reference but an address (of an int) and it is accepted by the receiver which is an int pointer.

Although It is generally a bad design to return these things, c++ allows you to .. the responsibility is all yours.. that's why c++ is a bit tricky lol

You can come across this problem if ,instead of an int , you deal with objects.. big objects.
It's reasonable you want to use a pointer or a reference BUT!
Scott Meyers tells you:
The right way to write a function that must return a NEW object is to have that function return a new object.
Effective c++ :: item 21

But x is not a new object.. ok item 22 explain you how to manage access policy for private data members..
{
public:
void setRW(int value){ rW=value;}
int getRW() const {return rW;}
private :
int rW; // read/write access
}

but it return an object.. ok

Item 28: AVOID RETURNING HANDLES TO OBJECT INTERNALS. is a perfect example that suits for you!

In short my suggestion is to read the entire book lolol
Somanycases

Answer 2

Not at all! A pointer is a variable, a reference is an alias and it cannot be assigned like a variable.. it must be assigned at declaration time and it never change the variable it references.

This topic is hard and is about design.

Answer 3

It's not bad style necessarily, it's perfectly valid to return references of private members. It just depends on what the programmer wants.

C++'s stl does it all the time, data structures return references to private data, std::vector's or std::map's at/operator[] and std::unique_ptr's are an example.

However in your code example I don't see much use in returning a reference, but then again, I might not be thinking of a good example right now.

Answer 4

Here is a very basic implementation of a vector:
https://code.sololearn.com/cWVV14yTK704/?ref=app

If you replace Vector<int> with std::vector<int> ( and include <vector> ) you would get the same output.

If I replace the functions which give references with setters and getters then code will get quite nasty and unreadable in this case. ( 1 liners become 2 liners, etc )

Making a member variable private is just to prevent direct access to it.

Whether you use getters/setters or functions which return references all depend on what you want.

If I want to check modifications/do any error checking before assigning a value to a member variable I would want to use a setter.

If I don't want modifications to directly change the member variable or I want to modify/encrypt the data before returning I would use a getter.

Both of these involve copying which can be expensive operations.
Data structures are usually speed critical which means you can't just go ahead and copy a 128 byte ( randomly selected size ) value, edit it and then copy it back.

So if you want speed or don't care about the member variable's value changing then returning references is the way to go.

Answer 5

Dennis Thanks for your answer.
Well, it's just an example, shouldn't mean anything.
In the original code you can change the pressure value for Navier Stokes Solver this way.

Could you give me an example about e.g. how std::vector gives references?

I still don't get why one might prefer this style instead of using getters and setters.
Or make the member variable public in the first place.
Isn't it the use of private members to avoid exactly such things like explicit changes on the member variable?

Answer 6

Thanks 👍
In terms of speed I understand, that's clear.

However this point
"Making a member variable private is just to prevent direct access to it"
is exactly what's driving me crazy 🙉😅
When you return a reference to it, you have direct access.

Answer 7

With that I actually mean preventing you from typing MyClass.a = 4; outside the class
over MyClass[0] = 4;

Not the fact that they have the same end result. operator[] could be const and still return a reference, but you wouldn't be able to modify it even though you have 'direct acess'. You don't have that control with the MyClass.a.

There is not much to it.

Just like pointers, you shouldn't overthink these things too much.

Answer 8

I just don't get the point why using a reference over using Class.a is prefered.
It's absolutely the same 😅
Both have direct access to the same place in memory.
So why not making it public then and save the coding of a method which returns the reference?^^

Answer 9

We could debate on this topic for a long time about what to use.

I think it all depends.

Returning private members, either by direct access or by reference, both break encapsulation, that is true, but sometimes that doesn't matter.

Most of the time you would be using getters and setters, which is the 'correct' way, as to not break encapsulation.

You could go ahead and access them directly, in very small classes, where it really doesn't matter. If you choose references instead, that's the programmer's choice.

Or big library code that can deal with big data and at the same time wants a universal way to access data and want to give control to the programmer, functions that return reference. :)

In the end it all boils down to what is most convenient and is within reason.

Answer 10

AZTECCO
I always thought pointer and reference is the same, only other syntax 😅

Good you mention Scott Meyers, totally forgot that I have this book somewhere^^

But in general it seems this topic is all about exceptions from exceptions of rules 😁

Thanks all :)