Free functions versus member functions

[janderson]

Kevin Bealer wrote:
 > Walter Bright Wrote:
 >>
 >> I eventually ran across this article by Scott Meyers 
http://www.ddj.com/cpp/184401197
 >> which made a lot of sense. It gives some good guidelines to use to 
make such decisions, and backs it up with reasoning that I find compelling.
 >>
 >> Isn't it funny how we've completed the circle? We went from all free 
functions in C, to all member functions in C++, and now back to free 
functions? <g>
 >
 > I like Meyer's point here.  My view is that classes provide the
 > following added value: they let you define a bunch of operations
 > without defining how they specifically will work.
 >
 > The example I think of is what I believe are two mistakes in the C++
 > STL, the first is 'sort'.  I think it "should" be a member function,
 > as vector::sort and list::sort have to be done differently for
 > efficiency reasons.

I've found sort as a non-member function quite useful when I needed to 
change the code from a std::vector to a standard C array.  A nice thing 
about non-member functions is they can work with privative types too.

 >

 > They give us the efficiency by making list::sort a member and vector
 > can be sorted with sort(v.begin(), v.end()).  But I think that's a
 > mistake, since you can't write a good template that calls x.sort()
 > and expect it to do the best thing.


I'm not sure what you what you are getting at here.  I don't think a 
member function list::sort was a good idea.


 > The other mistake (I think) is in the other direction, which is the
'extra' members that classes like string and vector have that give them
personalities. For example, methods like "push_back()" and "rfind()"
could be implemented externally for both string and vector, and it would
result in less complexity AND more capability. (Maybe they wanted
something like Boyer-Moore for string's find() related code?)
 >
 > Kevin
 >

Perhaps these could be external however it would probably restrict 
optimizations and verifications that can be applied to these (without 
exposing more of the class then you need too).  However it does seem odd 
to have find functions in 2 different places and my pet peeve with STL 
is that it has low discover-ability.

-Joel