Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-29 06:28:03

In message <8vttdv+tjq9_at_[hidden]>, William Kempf <sirwillard_at_my-
deja.com> writes
>> >> 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 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.

Aha, I see we are coming from different perspectives: I was taking the
point of the view that the object must be thread safe whereas you are
viewing thread safety as equivalent to synchronisation.

Whilst synchronisation is one way of ensuring thread safety in the
presence of change, my point was that lock-free synchronisation (eg
atomic operations) and immutable objects satisfied the requirement. In
other words, the requirement would be that operator(), or any other op,
would be thread safe, for some appropriate implementation of thread
safety for the functional object. Sorry for the confusion, I should have
been more explicit.

>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 disagree fundamentally. The class we are discussing now is a class
that models that addresses the issue of wrapping up an object of
arbitrary type that satisfies function call requirements in a single
class whose instances are copyable. Sharing is orthogonal -- once again,
express independent ideas independently :-)

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

Except compiler support and a clarification on the standard, I can now
add :->

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

Ternary and quaternary :-) I suggested nullary, unary and binary because
they are the only we have support/concepts for in Boost and the
standard.

Kevlin
____________________________________________________________

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