Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-22 16:29:44

--- In boost_at_[hidden], "Peter Dimov" <pdimov_at_m...> wrote:
> From: "William Kempf" <sirwillard_at_m...>
> > --- In boost_at_[hidden], "Peter Dimov" <pdimov_at_m...> wrote:
> > > A list of pros and cons won't help, because a cloning callback 
and a
> > > reference counted callback are different concepts. Sometimes 
you'll
> > need the
> > > one, sometimes the other.
> >
> > This I'm not so sure about.  Yes, their behavior is radically
> > different.  However, I find it difficult to think of specific
> > situations where one would be the answer while the other would 
not.
> > Can you spark my thinking on this?
> 
> The "pro ref-counting" example is easy, I already offered it (the 
STL
> algorithms assume that copies are equivalent.)
> 
> To be honest, I don't immediately see a killer example that 
demonstrates a
> situation where a cloning callback would be the answer but the 
counted
> callback will not fit. Cloning just "feels right" to me.
> 
> The counted callback more closely mirrors a function pointer, in 
the case
> where the function has state (static variables.)
> 
> All this seems to point toward reference counted semantics, but as 
I said,
> my intuition doesn't agree. :-)

Kevlin was swaying me towards cloning, now you're swaying me 
back ;).  Cloning would definately be simpler, and I agree about the 
intuition, but your other arguments/examples show why we should have 
ref versions at the very least.
 
> Here's another tricky point:
> 
> callback<int, int> c(F());
> callback<void, char> c2(c);
> 
> Do c and c2 share the same function object?

Sort of.  This will create a callback that wraps a functor, that 
happens to be a callback with a different signature.  So, internally 
there will be a shared functor, but it will be shared at different 
levels (if that makes sense).

> (The prototype implementations, including mine, don't handle this 
case
> "correctly", I believe, but for now, let's ignore them and look at 
the
> design.)

I'm not sure what you think is "correct", but no, I don't *think* the 
implementations posted so far have addressed this idiom to the extent 
that it should be addressed yet.

> Another question about the example above, suppose that F has two 
overloads:
> 
> struct F
> {
>     int operator()(int);
>     void operator()(char);
> };
> 
> Which op() should c2('A') call?

Again, because of the wrapping it will call the int (*)(int) version.

I think this is the "proper" way to handle this.  I don't think what 
you've shown should be consider a copy constructor (i.e. it's not the 
internals that are copied).

Bill Kempf