Printable View
I sign reads "loss of encapsulation" and the accompanying lights and siren are indicating, at least in my head, that friendship is best for Humans but not always for classes.
Can someone please expound this new year's day on why I should care about friendship in c++ as it relates to classes and member functions?
Thank you
Honestly I had never heard of the friend feature to c++ until tonight with Thames' post. I am definitely going to have to look it up and do some research on its usage.
I am assuming you already read that thread? I believe grumpy and a few others spoke of some of the benifits and disadvantages of the friend feature.
No, I have not read nor was I aware that a detailed post regarding friendship was around. I will have to check it out.Quote:
Originally Posted by Lesshardtofind
The thread Lesshardtofind is referencing is over here, though at the time of this post the "when is friendship appropriate" discussion didnt really have much meat to it. As grumpy mentioned, the advantage of friendship is that you are given better control over which classes or functions may access sensitive data. Its also important to note that friendships arent always necessary and are very easily used inappropriately (which I feel is what std10093 was trying to say in the other thread).
A bad example of friendship would be if you have a screensaver program with a Ball class, a Box class, and a Triangle class, with the potential to add more shapes later. Each class has data members that keep track of the object's position and velocity on the screen, and must be able to bounce off eachother. Friendship could be used here, making every class every other's friend, but is considered bad technique since you would be just as well to mark the data members public or create interfacing methods.
A good example of friendship would be a banking program with an Account class (keeps track of the money in an account), an ATM class (manages the money in an account), and an AverageJoe class (people that use the ATM). You want the ATM to be able to check and alter the total held in Account, but you dont want AverageJoe to be able to do so. If you create interfacing methods in Account to return or change it, AverageJoe would also be able to use those methods. However, if you mark ATM or a member function as a friend, you have your solution.
Hope that helps! If you need more reading, check out Friendship and inheritance - C++ Documentation. Happy holidays :)
If you haven't heard of friend or needed it very often, that's probably a good thing. If friendship is appropriate, your design wouldn't work without it. As with any way to grant access rights, it is about selecting the best, as in most restrictive, level of access.
Let's take a closer look at the stream operator >> and operator << first. It is not all that hard to code an operator << in terms of normal "getter functions", but once you make "getter" functions, any other object can call those. This can be a drawback despite being completely safe: this exposes the implementation of the object, and the level of access could undermine your intentions. If you print an ID by calling "int getID() const;" you might otherwise not have a use for such a function, so a friend operator is better. You should see you have a similar problem with the operator >> being implemented in terms of "setter" functions. The example of ATMs and bank accounts has a similar conundrum: it is perfectly possible to write an account class that uses getters and setters, but it exposes the implementation. More importantly, it might be your intention that it is only possible to modify a bank account through an ATM, instead of just anywhere in the whole program. In each example use of friend, you are saying as the implementer of the class to the client: perform this action with this class using this friend method only, or perform these actions only with this friend class.
That last sentence cannot be repeated enough times. A friend method or class is just another arm of your public interface, where other choices are too intrusive. "Exposing the implementation" may not seem like a big deal, but it can be, especially if you use a certain idiom.
And the whole idea of "coupling" is just what it advertizes... in many cases, a specific design decision like using "friend" marries two things that used to have a wall of separation. I hope that clears up the other thread.
These articles concentrate more on membership than friendship, but they should also give you some insight on the topic:
How Non-Member Functions Improve Encapsulation by Scott Meyers
GotW #84: Monoliths "Unstrung" by Herb Sutter
The C++ Style Sweet Spot: Designing Simple Interfaces (inteview of Bjarne Stroustrup)
I'm not going to write a treatise on friend, but will make a few observations.
1) Friendship is a design and implementation decision, not a decision about how a class (or instances of the class) will be used. By granting friendship, a class allows other entities (other classes, functions, even a member function of a class) direct access to its private and protected implementation details. It is therefore necessary to specify exactly what a friend is allowed to do as carefully as you would specify what member function would do.
2) Anything that a class declares as a friend becomes part of the public interface of that class. There is no difference between a friend doing something it shouldn't with private data (or operations) versus the class' member function doing something it shouldn't with that same private data. Similarly, there is no difference between a friend doing something with protected data (or operations) and the class member functions, or member functions of derived classes, doing something they shouldn't with that protected data.
3) This is completely different from inheritance. A derived class cannot access private members of a base class. Protected members of a base class do not become public members of a derived class.
4) Used with care, friends actually support comparable or greater degrees of encapsulation than do member functions (as they are not members, they can be used to improve encapsulation). A function that returns a reference or pointer to a class' internal data actually provides less protection of that data than does a friend (unless that friend does the unfriendly - or over friendly, depending on your viewpoint - act of exposing a reference or pointer to the class' internal data).
5) Friends do not replace any need for getter or setter functions. However, if some function (such as streaming operators) needs access to data for which there is no getter or setter, then that operation needs to be a friend. If it makes sense for the getters and setters to be public, then a function which can do its job completely by use of those getters and setters does not need to be a friend. With careful use of friends, a class does not need to expose getters or setters unless the designer or the class chooses to do so.
6) Since friends, like public member functions are part of the public interface of a class, their implementation is also sensitive to changes of that class's private (and protected) implementation details. So, for example, if the private data of a class measures length in centimetres, then all friends and all member functions must be implemented with that in mind. If the implementation changes to store length in metres, all friends and all member functions must be updated accordingly. If those friends and member functions are consistent in how they expose length to code outside the class (eg they all provide lengths in inches) then code which uses those member functions or friends does not need to change.
It would probably help if people understood that encapsulation is a measure of how sensitive code is to changes of class implementation. The smaller the number of functions that break when internal class representations change, the greater the encapsulation.
No, I would argue that they do not support greater degrees of encapsulation than do member functions: the fact that they are not members is not relevant here, since either way "the smaller the number of functions that break when internal class representations change, the greater the encapsulation".Quote:
Originally Posted by grumpy
It depends on how much abstraction you're interested in. Access of class members by member functions tends to be more granular than access by friends, simply because it is often easier to get ones mind around an external function accessing multiple data members of a class (or even data belonging to multiple instances) than it is to get ones mind around a member function doing so.Quote:
Originally Posted by laserlight
A single friend function that is exposed to multiple changes of internal representation represents a greater level of encapsulation than multiple getters/setters that each access one of the internal data elements. (Again assuming the measure of encapsulation is number of functions that must be updated when internal representations change - since it is rare for a change of internal representation to affect only one data member among several).
This observation does not show that "friends actually support comparable or greater degrees of encapsulation than do member functions". Rather, it is a practical point concerning the tendency of those who design classes with respect to these features.Quote:
Originally Posted by grumpy
However, it does not represent a greater level of encapsulation than a rough equivalent single member function "that is exposed to multiple changes of internal representation". This is why I agree with "comparable", but not with "greater". If we're looking at a choice between making a function a member or a friend because it needs access to the internals, then I would say to prefer making it a member, unless there is a compelling reason to make it a friend (e.g., because the first parameter must be of a different type, or it is already a member of a different class).Quote:
Originally Posted by grumpy
Sure, although that tendency of those who design classes does have an effect on various measures - such as those related to sensitivity to change.Quote:
Originally Posted by laserlight
Also, bear in mind that the probability of (A or B) is never less than the probability of A. ;)
Suppose that you have to write your own STL-like container. The iterators might need to access the internals of the data structure. When you implement the ++ operator, for instance, you have two options:Quote:
Originally Posted by Imanuel
1) Provide, in the container class, a _public_ method, and have it called from the ++ operator of the iterator class.
2) Declare, in the container class, that the iterator class is a friend. Then you can choose to access directly to the internals of the container from the iterator class, or use intermediate _private_ methods of the container.
The second option is somehow cleaner, The clients (the users of your container) will have only one way to call each operation (++, --, etc.).
Happy new year!
If the iterator class is declared within the container class, then it would have access to the private members of the container class even without being declared a friend since a nested class is permitted such access.Quote:
Originally Posted by comocomocomo
Very interesting! Well, that narrows my list of real-life, good 'friend' examples (from my own experience) to... zero ;-)Quote:
Originally Posted by laserlight
Well, overloading stream operators often need the declarations to be 'friendly'.Quote:
Originally Posted by comocomocomo
I have seen that example in a lot of places, so I think it is not evil™.
In these cases I prefer to implement the functionality in a public method (virtual, most of the times). The operator << receives a reference to the object and calls the virtual method.Quote:
Originally Posted by manasij7479
Neat idea!Quote:
Originally Posted by comocomocomo
Though that makes the overloading somewhat pointless, as you could ( and probably should, to avoid large copy operations ) just
use that member function to plug its string/stream output to the stream <</>> was to be called with.
I think it's the other way around. If everything is passed by reference, my design requires no copy operations. If you put the text in a std::string and then pass it to the op<< for strings, you create a temporary copy of the data: the string itself!Quote:
Originally Posted by manasij7479
The clients are supposed to call the operator<< and not the method print(). The point is: do we care? There is no integrity issue. The only problem is that the public interface is bloated with one more name. If you think this is too bad, make print() private and 'friend' the operator<<. I usually don't.Code:#include <iostream>
class A
{
public:
virtual void print (std::ostream & os) const
{ os << "Object of class A" << std::endl; }
virtual ~A () {}
};
inline std::ostream & operator<< (std::ostream & os,
const A & a)
{
a.print (os);
return os;
}
class B : public A
{
public:
virtual void print (std::ostream & os) const
{ os << "Object of class B" << std::endl; }
};
using namespace std;
int main ()
{
A * p, * q; // Note: both are pointers to A
p = new A; // Object of base class
q = new B; // Object of derived class
cout << *p // Prints: "Object of class A"
<< *q // Prints: "Object of class B"
<< endl;
delete p;
delete q;
return 0;
}
Oh, and you might want B's print() to show the inherited part of the object by calling A's print():
In this case, if you decide to hide print() from the clients, you would have to make it protected, not private.Code:class B : public A
{
public:
virtual void print (std::ostream & os) const
{
os << "Object of class B. Base: ";
A::print (os);
}
//...
If I leave print() public, you might argue that my operator<< is just syntax sugar, but... yum! :-)
I don't see the importance of inheritance here at all. You still write two methods to call through yet another method....
That is fine because the overloaded operator<< cannot be a virtual member function, so making use of a virtual print function is normal. If you want, you can keep only the overloaded operator<< as the public interface by declaring it as a friend of the base class, then having the virtual print function be private (or at least protected), i.e., implement the non-virtual interface idiom.Quote:
Originally Posted by whiteflags
Of course, this only makes sense if inheritance is used, otherwise it would be unnecessary work, hence comocomocomo's preference betrays a possible overuse of inheritance ;)
You are right. I included inheritance in an attempt to address the most general case.Quote:
Originally Posted by whiteflags
When using inheritance, you just need to write the operator<< once. I find this fact very interesting. That's all.
Dunno, I don't find that terribly interesting: when not using inheritance, you also just need to write the operator<< once. In my opinion, the main advantage of using a print member function is that it can be virtual, and in fact the typical reason for having a print member function in addition to operator<< is that it is virtual.Quote:
Originally Posted by comocomocomo
I'm reading Scott Meyers' "Effective C++, 3rd edition". I'm still with item 19, but I followed some cross references and ended up in item 46: "Define non-member functions inside templates when type conversions are desired". The title does not mention it, but the trick suggested requires the use of 'friend'.
Basically, we have a class that should behave as a number (complex, rational... whatever). We define operator overloads (sum, product..) outside the class because we want automatic type conversions on both parameters.
Then we tempatise the whole design. The class becomes a template. The external operators become templates too. And then the automatic conversions don't work anymore!
The compiler won't try to cast the parameters to the template instantiation because it still hasn't decided which template instace to use.
The solution: 'friend' the desired operators instantiation from within the class template. The purpose is not letting them access the internals, but have them declared (or should I say instantiated...).
Isn't it amazing.