From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-11-20 12:59:15
On Mon, 20 Nov 2000 16:51:19 -0000
"William Kempf" <sirwillard_at_[hidden]> wrote:
> > > (This is one of the things the really confused people in SigC,
> > > are multiple formulations there to cover the bad case compilers.
> > > makes for reams of code which just gets skipped on most
> > After uploading the newest version of the callback library
> yesterday I was lamenting the ugliness of the resulting code. As
> careful as I was, the VC++ hacks have produced almost illegible
> source from reasonably simple code.
> It doesn't seem that bad to me (at least at the public interface
> level... I've yet to look in the ::detail sub-namespace).
> Unfortunately, portable code will often have ugly warts, and this is
> made worse by non-conforming or buggy compilers. However, you've
> done a good job of hiding the ugliness from the user.
This will change somewhat, because callback should really inherit from a callback_impl which is specialized based on the number of parameters (just like function_callback_impl in details/callback.hpp). Otherwise, we have extranneous, unusable operator() overloads in the main callback class.
> I'm still looking over your code. What I've seen so far looks
> exactly like what I had in mind and seems to be well implemented.
> After considering the differences between this and Slots we should
> decide if one is better than the other, or if both are legitimate for
> different purposes (the likely result, I think). Then, if callbacks
> are considered useful instead of or in addition to Slots, I'd
> recommend your code as the basis for finalizing the idea.
> That said, I do have one comment/question about your code. Your
> boost::callback class has several functions that operate on a
> base_type (typedefed to the boost::detail template that is the bridge
> class for external polymorphism). Why is this? I see nothing in the
> implementation that would use them. If the implementation doesn't
> use them they should not exist, because users should not be using
> types from the detail namespace any way (even if they are typedefed
> within the callback). If the implementation does use them then for
> the same reason I'd think they should be private. Removal of them
> would greatly simplify the interface.
The intention was that other callback-like implementations (slots, perhaps?) could share the same bridge, but on second thought this doesn't provide much of an advantagw. When I dig through and fix the problem mentioned above (extra operator() overloads), I'll clean up the interface.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk