I am trying to understand C++ friend. When is the good use case to use friend? I suppose if we want to let another class have access to another classes attributes, why don't we just make it as public or inherit from that class instead?
Thank you for your help.
Making a member of the class public means granting everyone access to it, thus breaking encapsulation completely.
Inheriting from a class is often not desirable, if the friend class is not meant to be a subclass. Subclassing just to get access to the internals of a class is a grave design mistake. And even a subclass can't see the private members of its base class.
A typical usage of friend is for operators that can't be members, such as stream operators, operator+ etc. In these cases, the actual class they are associated with is not (always) the first parameter of the function, so the function can't be implemented as a member method.
Another example is implementing an iterator for a collection. The iterator (and only the iterator) needs to see the internals of its parent collection, however it is not a subclass of the collection.
The example I've most often seen friend classes used for in C++ is in unit testing. Unit tests typically want to know all about your internals, but are not part of you, and it makes no sense to have them try to inherit from you.
If you aren't familiar with writing unit tests, I'd suggest that you start right away.
I've found friend classes in C++ to be useful where in Java I would have used package access. That is, I have a bunch of classes that are so intimately related that they are written and maintained as a unit, in the same source file(s). Anyone working on one of them is really working on all of them. The invariants that they maintain they maintain together. It makes sense for them to see each other's internals so they can maintain their shared invariant.
What doesn't make sense is protected access. If it's not safe to expose some part of my internals to the public, it's not safe to expose it to whatever jackanapes comes along later in a completely unrelated project and claims to be my subclass. Let subclasses use my public interface, just like everyone else. (Unless they're friends, but in that case I wrote them and implemented them in the same source, so they're hardly from some other project.)
This question should be on stackoverflow. Anyway You use a friend only when you want to share the private parts of your class with another class(or classes) but not with anyone else. If you make them public everyone can see your private parts( pun intended ;-P). There are two important restrictions which enforce privacy: 1) you have to specify who your friend is. No one else can be a freind. 2) you cannot inherit "friendly" behaviour in the friend class's subclasses
A typical use is to grant access to functions that form part of the class' interface, but thanks to other rules can't really be part of the class proper. Inserters/extractors for iostreams are a classic example:
namespace whatever {
class something {
// ...
friend std::ostream &operator<<(std::ostream &os, something const &thing);
friend std::istream &operator>>(std::istream &is, something &thing);
};
}
Making these operators members of the class will not work. An I/O operation looks something like:
whatever::something thing;
std::cout << thing;
For an operator implemented as a member function, this would be resolved as:
std::cout.operator<<(thing);
I.e., the function would have to be a member of std::cout, not of something. Since we don't want to modify std::ostream constantly, our only reasonable option is to overload the operator with a free function instead of a member function. That leaves us with two possibilities: either ignore encapsulation completely, and make everything in the class public, or else keep it private, but grant access to the few things that really need it.
Making another class a friend is rather less common. In this case, you're typically creating something on the order of a module or subsystem -- a set of classes that work together and have some degree of special access to each other that's not granted to the world at large.
There's a pretty good example of the need for friend classes in this request for friend-like classes in C#, a language that doesn't have them.
Quoted wholesale here:
Access modifiers in .NET were designed with the idea that you can trust your co-workers to know how the code works and hence not slip up and introduce a bug.
This idea is flawed though. Software development is so complicated that an experienced programmer knows not to even trust him/herself! For this reason, experienced programmers prefer to write code which, by design, cannot be broken through accidental misuse. .NET provides the tools to do this when only one class is involved, but the moment a programmer attempts to create a bullet-proof set of two or three interacting classes, this breaks down.
The .NET-intended approach to this is to mark the shared members as "internal", which allows the classes to interact with each others' internals. Unfortunately this also allows every other class in the assembly to mess with the internals, be it by accident or intentionally.
Mads Torgersen, C# Language PM, has even replied to this proposal, stating that the feels the concern is indeed a valid one, but being unsure about the specific implementation suggested there.
The C++ friend is just one of the ways to tackle the problem described.
When you want your classes to have monogamous relationships.
E.g. when you do not want unknown classes to access their privates, but their partners do need access.
Lets say there is an external function which requires you to perform operations on private or protected members of two different classes within your program. now, in order for that function to gain access and actualy use these class members you have to make it a friend of both classes. Keeping in mind that by making it a friend of both these classes does'nt make it a member of the classes it just gains the prevelage to refer to the private or protected members of these classes. I can say that you would need to use a friend function when you want to operate on objects of two different classes. Though the overuse of friend function and class can reduce the value of encapsulation.
