Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-23 14:47:36

In message <8vja6c+jdh4_at_[hidden]>, 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.

Whilst I consider this a possible approach, I do not favour it: overly
restrictive and overly simplifying.

>How much coupling do 
>we
>> want? I think that the amount of configuration involved would put 
>me off
>> this solution.
>
>You need to strive for no coupling, else you infringe on functor 
>libraries of the past and future.

My feelings precisely.

>> 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 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.

>Not a big deal, though, since (*s)(); 
>will work.

Except that algorithms that work on function objects will barf on this
because they expect the direct form of function invocation.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________