I have an object oriented programming with c++ course this semester at college and we were learning about friend functions.
I instinctively dislike them for their ability to bypass the security that Encapsulation and Data hiding provide, I read a few articles on the internet and some people thought that it was a good idea with some legitimate uses.
What would an OOPs expert say about friend fucntions in C++? Should I just skim over it or should I learn more about it?
It is not always convenient to make all the functions related to a C++ class members of that class. For example, imagine an implementation of vector algebra with scalar multiplication. We want to write:
double a;
Vector v, w;
w = v * a;
We can do this with a member function:
public class Vector {
...
Vector operator*(double a);
}
But we would also like to write:
w = a * v
This requires a free function:
Vector operator*(double a, Vector v)
The friend keyword was added to C++ to support this usage. The free function is part of the Vector class implementation, and should be declared in the same header and implemented in the same source file.
Similarly we may use friend to simplify the implementation of tightly coupled classes, like a collection and an iterator. Again, I would declare both classes in the same header, and implement them in the same source file.
inline Vector operator*(double a, Vector v) { return v*a; }. Canonical solution in fact.
inline Vector operator*(double a, Vector v) { return -v*a; } and that still doesn't require friendship.
Friend functions are no different to member functions in terms of encapsulation. They can, however, offer other advantages- such as being more generic, especially where templates are concerned. In addition, some operators can only be specified as free functions, so if you want them to have member access, you must friend.
It's better to friend a single function than be forced to make something you don't want to be public. That means the whole world can use it- instead of just one function.
friend a function which is also "private", such as only declared in a single TU.
Does "friend" violate encapsulation?
No. It does not. "Friend" is an explicit mechanism for granting access, just like membership. You cannot (in a standard conforming program) grant yourself access to a class without modifying its source.
"What would an OOPs expert say ..." It mostly depends on how expert he is in C++, that -by its own specification - is not (and doesn't want to be) a language for purist.
OOP Zealots don't use C++ (they prefer Smalltalk, and like Java).
Functional programming zelots don't use C++ (they prefer LISP, and its successors)
The most of OOP experts dislike friend function simply because they want the OOP part of C++ to behave like Smalltalk. But C++ is not Smalltalk, and they cannot even understand that friend don't break encapsulation, for the very simple reason that a function cannot be friend of your class without your class wants it.
And from the "functionality" stand point, between a.fn(b) and fn(a,b) there is no difference (where fn is a friend): the involved parties are the same. Simply, one syntax may be more suitable than another: if fn is commutative regarding a and b, fn(a,b) is probably more suitable then a.fn(b) (where a looks having a "special role" that, in fact, it doesn't.)
If you're passionate about what you do, you would be learning everything about C++. Learn what they're used for, how to use them, and then - and only then - decide not to use them. At the very least, you'll be prepared when reading someone else's code that uses this facet of C++.
The C++ FAQ is succinct:
Use a member when you can, and a friend when you have to.
The FAQ presents one of the more useful ways of thinking about friendship:
Many people think of a friend function as something outside the class. Instead, try thinking of a friend function as part of the class's public interface. A friend function in the class declaration doesn't violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class's non-public parts.
Perhaps the most common use of friend functions is overloading << for I/O.
Friend functions are best used for user-defined operator definitions. They are useful in other situations, but if you find yourself specifying friend classes frequently then you may be on a design detour (just a good self-check to use while writing code).
Do be careful about the "security" statement in the original question. Access modifiers are there to prevent you from writing bad code on accident, just like the compiler in a way. Access modifiers limit the interface, and serve to communicate what functions are important to use the class (public and protected), and which ones were created as part of making the class prettier for the maintainers (private). Modifiers do not constitute security in that there are many ways to get at private data. For example, get a pointer to the class and its size, and go fishing.
C++ friend functions are closely related to the following functionality:
This means that they do not have this-pointer and thus are outside of the class/object. On the other hand, they often take parameters that make them again belong to the class. Here's some example which clarifies the link:
class B;
class A {
public:
friend void f(A &a, B &b);
private:
int m_a;
};
class B {
public:
friend void f(A &a, B &b);
private:
int m_b;
};
void f(A &a, B &b) { /* uses both A's and B's private data */ }
The only difference between static functions and friend functions is that a friend function can use several classes.
Using friend mechanism in c++ requires programmers that have about 10-15 years experience with the c++ way of programming, and thus initially you should avoid it. It's advanced feature.
