On Wed, May 14, 2008 at 10:31 AM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Wed, May 14, 2008 at 7:01 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
I suspect that there are really two tools here. One which allows separate function objects to be bound to each signature, more like a fusion sequence or something. The other binds all overloads to a single object. Neither one is easily implementable in terms of the other. If all the signatures are bound at once, then it is difficult to later change just one. If the functions are bound separately, then there is a significant size overhead compared to using a single object.
Great point Steven.
Yes, my proposal would not let one rebind signatures separately (not easily at least). If this is an useful thing (really, I do not know), then please Marco, disregard most of my comments, probably I'm really looking for something else.
--
Yes. I fully agree with Steven and with you. But because I have already implemented both features (indeed also a third one, see below for passing a boost::ref(poly_obj) ) I propose to do the following: - Rename proposed set_all() in set_polymorphic_object() The point here is not to set all the msf slots, but to assign a poly oject to a msf, that's the goal, the fact that doing this the slots become all occupied is a side effect. So let the API reflect this. Also IMHO would be misleading using operator=() in this case because assigning a poly object opens the door to a whole set (currently 3) of different behaviours that are not present in the other cases so let the API reflect this. - Default to rebind signatures separately as suggested by Daniel and seconded by Giovanni. The point here is that the "natural" extension is doing this and the other behaviour is the sub-optimal one as pointed out by Steven and Giovanni due to size overhead and possibly not intuitive behaviour as suggested by Daniel - Allow the bind to a single copy of poly objects as requested by Giovanni: The point is that this feature as been requested ;-) and is possible to implement it easily although with sub-optimal size. The user API for this will be a boolean argument defaulted to false in set_polymorphic_object() - Allow to call set_polymorphic_object( boost::ref(poly_obj) ) The point here is completeness of solution because boost::function can do this and because there are cases in which I want to modify a poly_object state externally from MSF while poly_obj is still bounded. I think the 3 different handling of poly objects cover this case at least as long as msf is considered just a boost::function extension, as I would be glad to stick with. The case of interest for Giovanni is implemented in a performance point of view sub-optimal way but it works and anyway the _real_ (read benchmarked) performance penalty is still not very clear to me IMHO. Comments? Thanks Marco