Marco Costalba wrote:
Giovanni Piero Deretta wrote:
Marco Costalba wrote:
Giovanni Piero Deretta wrote:
I think that in your case, using operator= is confusing because you are not really reassigning the MSF but just adding an overload. What if operator= tries to bind all signatures at once (and thus allows for boost::function like adaptability) and operator+= (or an explicit add member function) is strict and allows to replace a single overload?
operator+= is a nice idea, like an explicit set() or add() method. I have been stick to operator=() just to follow boost::function API, but I agree in case of MSF this could be confusing...
Well, in boost::function, operator= replaces the content of the function, which is not true in MSF case.
In MSF it's true only for functions with same signature:
That's not the same thing. I think Giovanni was pointing out that operator= normally replace all of the content of boost::function... or anything else for that matter. I think this is important. I like the idea of providing an assign() for a sequence of callable objects implementing each signature. However, operator= should retain its usual semantics of assigning the Whole thingy on the lhs and not merely an element of the thingy when the lhs is some sort of aggregate, which your multi-signature function is. <snip>
Operator+= might qualify as operator abuse, so an explicit set or add would be better (but personally have no strong opinion on this)
Well set() is already implemented and it works also with the msf code you (probably) have downloaded. It is just that is not a documented API. This is because boost.function that used to have set(), has discouraged and then removed that API.
I think it would be better to replace set() with insert() (or if you required the overload signature sequence to support random access, you could do something like at()). Your function object is, in a way, a collection of functions - an overload set - so it makes sense for it to act like familiar containers. Actually, you could literally call it boost::overload_set (after std::set and std::multiset) or with the random access requirement you could call it boost::overload_vector (after std::vector). You could call it boost::multifunction, but following std::multimap, std::multiset, etc. that makes me think of one signature mapped to multiple functions, which doesn't make sense. Regardless, I would look for opportunities to merge the STL APIs (concepts) for function objects and containers. Daniel Walker