Thanks for this. I'm in a Data Structures & Algorithms course and the topic of friend functions was introduced, but it wasn't clear why we'd want to use them. In my mind, I thought it just seemed like a way to create a backdoor to your protected member data, which seems.... risky at best. I wondered if this is something I'd actually ever want to use (we certainly don't seem to have any applications for it in the class) so this video was really helpful!
Cheers! Yeah, in practice the only time I've really used it is for print functions (or overloading operator>> for output). There are also friend classes which follow the same idea.
one use case that come to mind is linked list and node. linked list should be the only class that can access a node so linked list a friend class for node.
I just started using friend recently and felt proud of it, because I thought I've made some progress in my cpp learning, but now it seems that was a wrong decision. I shouldn't have used friend. 😂 Actually I even tried to use the "Client-Attorney" concept to hide part of the member functions. And it really doesn't look good, although it eventually works in my case. I wonder how to hide partial information without using friend. I thought that's a good way to encapsulate things, but the problem is it will disclose everything to the friends. Thank you for the explanation!
Cheers! Yes, friend is one of those features that has to be considered carefully. The pimpl idiom can generally be useful for hiding implementation details (th-cam.com/video/3mFpXNEB_AA/w-d-xo.html)
I didn't understand the second reason why we should avoid declaring friends in our classes . It starts at @10:57. Would you please explain that second reason? Also I think that'd be great if you could post a video on the combination of declaring friends on derived and base classes with different types of inheritance :) Thanks again for this informative video.
Cheers! The basic issue with friends classes is that they can break encapsulation when used improperly, and I think they're an easier feature to use improperly versus just using a member function in many cases. isocpp.org/wiki/faq/friends
Certainly could do that! In a perfect world, you'd catch any errors calling the public member functions, but perhaps there are some testing methodologies where you'd want to inject some errorful state into an object :)
Hello Mike, I was wondering why I get error on 'd.k;' ! Does it mean our friendship relationship doesn’t provide us access to the private members of the Base class? I thought friendship applies to the whole subject of a class (data members, member functions and Base) struct Base {
public: int i; protected: int j; private: int k; }; struct Derived : protected Base { friend int main(); public: int l; protected: int m; private: int n; }; int main() { Derived d; d.i = 1; d.j = 2; d.k = 3; d.l = 4; d.m = 5; d.n = 6; return 0; }
Aww, my OCD got me so fixated on "securtiy" that I had to watch this twice to actually focus on what you're saying, haha.
Ah, my bad -- thanks for sticking with it :)
Thanks for this. I'm in a Data Structures & Algorithms course and the topic of friend functions was introduced, but it wasn't clear why we'd want to use them. In my mind, I thought it just seemed like a way to create a backdoor to your protected member data, which seems.... risky at best. I wondered if this is something I'd actually ever want to use (we certainly don't seem to have any applications for it in the class) so this video was really helpful!
Cheers! Yeah, in practice the only time I've really used it is for print functions (or overloading operator>> for output). There are also friend classes which follow the same idea.
one use case that come to mind is linked list and node. linked list should be the only class that can access a node so linked list a friend class for node.
That could indeed be a strategy
I just started using friend recently and felt proud of it, because I thought I've made some progress in my cpp learning, but now it seems that was a wrong decision. I shouldn't have used friend. 😂 Actually I even tried to use the "Client-Attorney" concept to hide part of the member functions. And it really doesn't look good, although it eventually works in my case. I wonder how to hide partial information without using friend. I thought that's a good way to encapsulate things, but the problem is it will disclose everything to the friends. Thank you for the explanation!
Cheers! Yes, friend is one of those features that has to be considered carefully. The pimpl idiom can generally be useful for hiding implementation details (th-cam.com/video/3mFpXNEB_AA/w-d-xo.html)
@@MikeShah Thank you, Mike! I watched this video and will try to implement pIMPL next time. :D
Very nicely explained as always. Thank You.
Thank you for the kind words!
omg, you are my video professor in Northeastern !!!!!
I didn't understand the second reason why we should avoid declaring friends in our classes . It starts at @10:57. Would you please explain that second reason?
Also I think that'd be great if you could post a video on the combination of declaring friends on derived and base classes with different types of inheritance :)
Thanks again for this informative video.
Cheers! The basic issue with friends classes is that they can break encapsulation when used improperly, and I think they're an easier feature to use improperly versus just using a member function in many cases. isocpp.org/wiki/faq/friends
we can create a friend class which can be used as white box testing ?
Certainly could do that! In a perfect world, you'd catch any errors calling the public member functions, but perhaps there are some testing methodologies where you'd want to inject some errorful state into an object :)
Hello Mike,
I was wondering why I get error on 'd.k;' !
Does it mean our friendship relationship doesn’t provide us access to the private members of the Base class? I thought friendship applies to the whole subject of a class (data members, member functions and Base)
struct Base
{
public:
int i;
protected:
int j;
private:
int k;
};
struct Derived : protected Base
{
friend int main();
public:
int l;
protected:
int m;
private:
int n;
};
int main()
{
Derived d;
d.i = 1;
d.j = 2;
d.k = 3;
d.l = 4;
d.m = 5;
d.n = 6;
return 0;
}