Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-27 10:08:47

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vja6c+jdh4_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> >> In message <v03110703b6421d10642f@[153.32.222.4]>, Jesse Jones
> >> <jejones_at_a...> writes
> >> >>This means that we have three choices:
> >> >>
> >> >>(1) Impose this restriction.
> >> >
> >> >In other words the responsibility for making the functor call 
> >thread safe
> >> >relies on the functor itself. The functor can do this by not 
> >having any
> >> >mutable state or by using thread synchronization objects.
> >> 
> >> Exactly. It would be part and parcel of the function object
> >> requirements.
> >
> >Except that the requirements don't always exist.
> 
> I'm not sure what you mean by this: They would exist inasmuch as any
> template parameter requirements exist. And if they are not satisfied
> that is the problem of the client code rather than the supplied 
code.

I've been away for Turkey Day, so forgive me as I try to get back 
into the discussion...

I believe the argument was being made to internalize thread 
synchronization in the callback.  I stated that you don't always have 
a requirement that callbacks be thread safe (they can be used in 
single threaded programs, or can be insured to never be passed across 
thread boundaries).  Simply internalizing thread synchronization 
would be prohibitive in these cases, since it will add significant 
overhead in memory and speed.

> >> There's no restriction of the copyability. If you want reference
> >> counting, and you want to manage the risks of inter-thread 
sharing, 
> >you
> >> would write something like
> >> 
> >>         shared_ptr< function_ptr<void> > s(new_function_ptr(f));
> >>         ...
> >>         s();
> >
> >Except that shared_ptr doesn't have an operator() ;).  
> 
> At the moment... ;->

I'm not sure I'm in favor of it ever having such an operator.  The 
shared_ptr class is used to reference count dynamically created 
objects.  Operator() is used to call a function through a pointer to 
a function.  Functions aren't objects that need reference counting.

Granted, functors change this viewpoint, but they do so by moving 
into brand new territory.  I don't think the generic shared_ptr is 
appropriate here, but rather would see a class more suited to this 
task... which is what we're discussing now ;).
 
> >I don't think 
> >you can add it, either, as you don't know how many parameters the 
> >wrapped functor will take.  
> 
> I would presume that we would be adding overloads for the function
> object models we already cater for, ie nullary, unary and binary. No
> problem. Only requirement is that function_ptr export a result_type:
> 
> template<typename T> class shared_ptr {
>   public:
>     ...
>     typename T::result_type operator()() { return (*px)(); }
>     template<typename Arg>
>       typename T::result_type operator()(Arg a)
>         { return (*px)(a); }
>     template<typename FirstArg, typename SecondArg>
>       typename T::result_type operator()(FirstArg a, SecondArg b)
>         { return (*px)(a, b); }
>   private:
>     ...
>     T *px;
>     ...
> };
> 
> Leaving aside issues with our favourite compiler for the moment, I 
see
> no issues.

I just see major restrictions that shouldn't exist.  Why only 
nullary, unary and binary?  Where's trinary?  Quadnary?  (sp? on all 
of those)

Bill Kempf