Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk