Why does BGL use friend instead of member functions?
Hi, It appears, to me, that the boost graph classes use friend functions and apposed to member functions. What are the reasons for this design decision (I like it) and why is the graph passed as the last argument? Thanks, Louis. PS. Great graph - great book.
Hi Louis, On Sun, 11 Aug 2002, Louis Lavery wrote: Louis> It appears, to me, that the boost graph classes use friend functions Louis> and apposed to member functions. That is correct. Louis> What are the reasons for this design decision (I like it) and why is the Louis> graph passed as the last argument? For the most part, the differences between member functions and free functions are syntactic, and not very important, though people can get religious about them. However, I've got one technical reason for favoring free functions. A programmer can overload a free function for a type coming from a 3rd party without modifying the source code/definition of that type. There are several uses of this in the BGL. For example, Stanford GraphBase and LEDA graphs can both be used in BGL algorithms because of overloads in stanford_graph.hpp and leda_graph.hpp. One can even use std::vectorstd::list as a graph due to the overloads in vector_as_graph.hpp. Of course, there is way to adapt 3rd party classes into an interface with member functions. You create an adaptor class. However, the disadvantage of an adaptor class (compared to overloaded functions) is that one has to physically wrap and unwrap the objects as they go into/out of BGL algorithms. So the overloaded function route is more convenient. Granted, this is not a huge difference, but since there weren't other strong reasons, it was enough for me to choose member functions. My religious reason for choosing free functions is to send the message that BGL is a generic library, and not a traditional object-oriented library. OO was hip in the 80s and 90s, but its time we moved past it :) Louis> Thanks, Louis> Louis> Louis. Louis> Louis> PS. Great graph - great book. Thanks! Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek@osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 855-3608 ----------------------------------------------------------------------
participants (2)
-
Jeremy Siek
-
Louis Lavery