Boost logo

Boost :

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

In message <8vja6c+jdh4_at_[hidden]>, William Kempf <sirwillard_at_my-> writes
>--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
>> In message <v03110703b6421d10642f@[]>, 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
>> 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,
>> 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 {
    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); }
    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 Henney phone: +44 117 942 2990
  Curbralan Limited mobile: +44 7801 073 508
  mailto:kevlin_at_[hidden] fax: +44 870 052 2289

Boost list run by bdawes at, gregod at, cpdaniel at, john at