Re: [boost] Re: Callbacks Again

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