[boost] programming guidelines, prefer free functions

From: jsiek_at_[hidden]
Date: 2000-08-17 10:20:33

Oh, and one other important advantage of free functions that I left
out. Free functions work well on basic types (whereas member function
don't work at all). See Dietmar's array_traits.hpp for an example.

BTW, if Stepanov hadn't been worried about appealing to the OO crowd,
he would have used free functions throughout STL.  Also, he would have
liked Bjarne to allow all operators to be written as free functions.

Ciao,

Jeremy

jsiek_at_[hidden] writes:
 > 
 > I have a suggestion for the boost programming guidelines.  As various
 > boost members have pointed out in the past (most recently Dave), it is
 > better to use free (non-member) functions over member functions in
 > public interfaces.
 > 
 > The rationale for this is that free functions allow for what I call
 > "external adaptation" (does anyone have a different name for this?).
 > Suppose you have a third party component (TPC) that you want to use,
 > but it doesn't match the interface needed for your softare. You don't
 > have access to the source code, so you can't change the TPC. If your
 > interface consists of member functions, you've only got one choice,
 > create a wrapper class for the TPC. Wrapper classes are difficult to
 > use and error prone. You have to be sure to implement the constructors
 > and destructors properly, and may have to write a bunch of delegating
 > functions. Also, every time a TPC object enters your code, you have to
 > wrap the object. On the other hand, if your interface consists only of
 > free functions, all you have to do is create specializations of these
 > functions for the TPC. Then you can use the TPC directly in your code.
 > Much simpler!
 > 
 > One possible complaint is that free functions rule out using dynamic
 > dispatch (virtual functions). On the contrary, simply specialize the
 > free function in terms of the abstract base class, and write a
 > one-liner that dispatches to the virtual function.
 > 
 > Cheers,
 > 
 > Jeremy
 > 
 > 
 > 
 > 
 > 
 > 
 >