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:
[snip]
> > > (This is one of the things the really confused people in SigC,
> there
> > > are multiple formulations there to cover the bad case compilers.
> It
> > > makes for reams of code which just gets skipped on most
> compilers.)
> >
> > 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.
[snip]
> 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.
Doug Gregor