1

Both int getArea(const Square& s); and int Square::getArea() const; do they same thing, are there times when one is preferable over the other?

  • Have a look at https://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 – Peter Oct 05 '20 at 01:54
  • Not that the Dr. Drobbs article is wrong -- but be very cautious when linking to articles that are *Two Decades Old*... When Win98 and SuSE 7.0 were the rage. – David C. Rankin Oct 05 '20 at 03:46
  • If you need to make the free function into a friend, the member is preferable. If you can implement the free function without friendship, you got your encapsulation right, probably. – StoryTeller - Unslander Monica Oct 05 '20 at 06:50

2 Answers2

1

Does getArea() need to use private members of Square? If it does, you would need to declare the non-member function (int getArea(const Square& s);) a friend. The consensus is that, in this case, you should prefer the member form (int Square::getArea() const;).

But what if you already have public member functions (maybe int Square::getSide() const; in your example) that allow making int getArea(const Square& s); a non-friend? Then there is a trade-off. From class Square maintenance perspective, it is better to use the non-member form, which is said to improve the class encapsulation (in other words, fewer functions have access to private variables).

However, if the class has a lot of users, you may want to make all possible functions members, so that users do not need to memorize which ones are non-members. Besides, IDEs may make member functions easier to discover (in Visual Studio, once you press ".", you get the list of all available public functions).

There were some attempts to eliminate this trade-off. One radical idea is to eliminate all non-virtual public functions, making non-members friends if needed. It can be combined with a wider accepted principle of NVI (non-virtual interface, i.e. making all virtual functions non-public). With this idea, you could get a consistent interface without sacrificing encapsulation. Unfortunately, this goes against long-standing C++ tradition.

Another idea is to change the language itself - let it treat x.f() and f(x) as synonyms, allowing to call even non-member function using member syntax. There was a proposal to C++ committee for it, but they could not agree on details.

Eugene
  • 6,194
  • 1
  • 20
  • 31
0

The first form is procedural, the second form is object-oriented.

The first form within a class really makes no sense, it's an anti-pattern. It's only really relevant in languages like C where you do not have classes, but you also don't have references either.

The second form only makes sense if you have a struct or class.

In short, use the second form unless you have a very compelling reason not to.

tadman
  • 208,517
  • 23
  • 234
  • 262
  • 1
    There is nothing wrong in using non-member functions. This alternative syntax does not make design less object-oriented. There are cases when non-member are preferred. – Eugene Oct 05 '20 at 05:07
  • 1
    @Eugene You're going to have to qualify that more specifically. – tadman Oct 05 '20 at 05:18
  • @Tadman: No need; the most well-renowned experts in our industry already did. :) https://stackoverflow.com/q/1692084/4386278 – Asteroids With Wings Oct 05 '20 at 14:10