3

I would like to know what could be reasons to provide a public access method returning a reference instead of making the member public. QPoint has methods int& rxand int& ry that let me directly manipulate the coordinates.

I guess the implentation looks similar to this:

public:
    int& rx(){return x;}
private:
    int x;

The only idea I had so far is the following: By keeping the member private and "only" providing a reference, the class can still change to use a different data type for its coordinates and while still "somehow" returning a reference to an int. However, this "somehow" would always need an int member. Once the reference leaked, the member pratically cannot change anymore. So this cannot be the reason.

In a related question the accepted answer suggests to rather make the member public instead of returning the reference.

Is there any benefit of returning a reference instead of making the member public (in the general case)? Or is this just Qt specific (QPoint specific?) design?

EDIT: QPoint in Qt4

Community
  • 1
  • 1
463035818_is_not_an_ai
  • 109,796
  • 11
  • 89
  • 185
  • 2
    It's useful for C# wrappers calling into C++ because such functions can be made to appear as properties. – AndyG Jun 08 '15 at 19:34

1 Answers1

3

In general, returning a member by reference breaks as much encapsulation as having a public member, and neither is encouraged.

I suppose when a class is sufficiently simple (plain old data-it is anticipated that neither interface, nor data will ever change), one could make all its members public. Returning a non const reference had the same effect. All encapsulation is broken.

With respect to your question, there is no benefit.

In addition to my answer, similar answers have been given here

Community
  • 1
  • 1
Werner Erasmus
  • 3,988
  • 17
  • 31
  • Now when I think about it, it is kinda obvious: A reference variable is (sloppy speaking) just an alias. Thus it really does not make any difference. AndyG might be right on C# properties. However, afaik Qt properties need QObject as a superclass which is not the case for QPoint. – 463035818_is_not_an_ai Jun 08 '15 at 20:57
  • This answer assumes the implementation of `QPoit::rx()` is the same as posted by OP. – Raydel Miranda Jun 08 '15 at 21:03
  • Why the Qt implementers decided on this only they would know. It's a very simple class, and I suppose it had to do with backward compatibility. I've read their documentation, and it seems as lame excuse... Some Qt api implementor might comment. Look at boost point, for example... – Werner Erasmus Jun 08 '15 at 21:13
  • Well, you guys won the battle, if @tobi303 found the code and it just return a reference as he says, then I cannot come out with a good example on a use case that justify returning the reference instead making that member public. – Raydel Miranda Jun 09 '15 at 11:50
  • A reference is not the same as making a private member public. A reference is , simply, a reference, public or private, so what? References are very useful, read *great benefits*, in for example UI programming where you may have a widget manipulating an underlying value. You just gotta know what you are doing, and why. – Totte Karlsson Sep 05 '18 at 20:46
  • @TotteKarlsson, how does exposing a reference differ from making a member public, especially when it is mutable? It breaks encapsulation, period. It's not about knowing what you're doing, its about writing programs that others can't break easily. Returning a reference directly gives outside code the ability to change your guts, and you have no control which code does that. That means the other code must be intimate with the possibly states of your classes guts (to not cause errors), which breaks encapsulation. Code that does this, is bad. – Werner Erasmus Sep 06 '18 at 14:59
  • @TotteKarlsson, I invite you to write a class exposing mutable (non-const) references to private members, and have it peer reviewed publicly – Werner Erasmus Sep 06 '18 at 15:00
  • @Werner-Erasmus Did I say that it does not break encapsulation? Of course it does, and for sure, sometimes the benefits of doing just that outweighs the cost of following "the rules". That's where knowing what you are doing, and why, is important. Its fine to break rules, if you know what you are doing, and as long it does not hurt anyone... – Totte Karlsson Sep 06 '18 at 18:48
  • @TotteKarlsson, Encapsulation is such an important part of software development, that when breaking encapsulation, you have to quantify per instance why the benefits outweigh the costs, and that no other way exists. It very rarely does (benefits outweigh), in fact, in my 18 years of developing software, I have never met such a case. The language c++ is designed in such a way that one doesn't have to (break encapsulation). State your usecase, quantify why, and only if an alternative cannot be found, then allow yourself that transgression – Werner Erasmus Sep 10 '18 at 08:21