Is returning references of member variables bad practice?

by

There are several reasons why returning references (or pointers) to the internals of a class are bad. Starting with (what I consider to be) the most important:

  1. Encapsulation is breached: you leak an implementation detail, which means that you can no longer alter your class internals as you wish. If you decided not to store first_ for example, but to compute it on the fly, how would you return a reference to it ? You cannot, thus you’re stuck.

  2. Invariant are no longer sustainable (in case of non-const reference): anybody may access and modify the attribute referred to at will, thus you cannot “monitor” its changes. It means that you cannot maintain an invariant of which this attribute is part. Essentially, your class is turning into a blob.

  3. Lifetime issues spring up: it’s easy to keep a reference or pointer to the attribute after the original object they belong to ceased to exist. This is of course undefined behavior. Most compilers will attempt to warn about keeping references to objects on the stack, for example, but I know of no compiler that managed to produce such warnings for references returned by functions or methods: you’re on your own.

As such, it is usually better not to give away references or pointers to attributes. Not even const ones!

For small values, it is generally sufficient to pass them by copy (both in and out), especially now with move semantics (on the way in).

For larger values, it really depends on the situation, sometimes a Proxy might alleviate your troubles.

Finally, note that for some classes, having public members is not so bad. What would be the point of encapsulating the members of a pair ? When you find yourself writing a class that is no more than a collection of attributes (no invariant whatsoever), then instead of getting all OO on us and writing a getter/setter pair for each of them, consider making them public instead.

More Related Contents:

  1. What does the following return type actually mean
  2. Why ‘&’ reference in not required in classes in C++?
  3. What are the differences between a pointer variable and a reference variable in C++?
  4. Should I prefer pointers or references in member data?
  5. Reason to Pass a Pointer by Reference in C++?
  6. C++ pass an array by reference
  7. Can we reassign the reference in C++?
  8. C++ standard: dereferencing NULL pointer to get a reference? [duplicate]
  9. int vs const int& [closed]
  10. How does a C++ reference look, memory-wise?
  11. What are the differences between a pointer variable and a reference variable?
  12. Is it safe to push_back an element from the same vector?
  13. ampersand (&) at the end of variable etc
  14. error: invalid initialization of non-const reference of type ‘int&’ from an rvalue of type ‘int’
  15. Declare a reference and initialize later?
  16. What is the difference between std::reference_wrapper and a simple pointer?
  17. Are there gotchas using varargs with reference parameters
  18. What is a constant reference? (not a reference to a constant)
  19. Why do some people prefer “T const&” over “const T&”?
  20. Why Can’t I store references in a `std::map` in C++?
  21. Modifying reference member from const member function in C++
  22. Why does std::forward have two overloads?
  23. prolonging the lifetime of temporaries
  24. Why we need to return reference to istream/ostream while overloading >> and
  25. Why is a c++ reference considered safer than a pointer?
  26. Is it safe to make a const reference member to a temporary variable?
  27. STL map containing references does not compile
  28. Meaning of *& and **& in C++
  29. Pass by pointer & Pass by reference [duplicate]
  30. Both asterisk and ampersand in a parameter

Leave a Comment