Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-30 14:45:55

In message <903oa0+7kdd_at_[hidden]>, William Kempf <sirwillard_at_my-
deja.com> writes
>> >I did not think you were coming from this angle because frankly, 
>it 
>> >can't be done generically.  
>> 
>> Of course it can! It's a non-functional requirement, just as many 
>of the
>> generic requirements are.
>
>I don't follow you here.  Pardon my denseness, but sometimes it seems 
>like english is a second language to me ;).

By requirements I am talking about the tabular style of type
requirements you find in the original STL and in the standard.

>> >A lot of function objects must carry 
>> >state around with them, state which is modified with each 
>invocation 
>> >of operator().  
>> 
>> Some, but certainly not the major part.
>
>That's debatable, and frankly depends on the application.

I am talking across applications. I can hand on heart say that I would
be surprised if you believed that the main use for function objects was
to carry modifiable state. They are a use, but I think relatively few
people believe they are the main use.

>> Function objects fall into three
>> categories wrt state:
>> 
>> (1) Stateless, eg functions, many of the function object types in 
>the
>> standard, many predicates, many transformations.
>
>Functions aren't necessarily stateless.  A static or global variable 
>can be used to maintain state (though difficult to use in MT apps).

This was addressed in the other email. What is meant here is pure
functions. Sorry, I should have been more explicit.

>> (2) Stateful but with fixed state, eg many bound function objects, 
>many
>> of the other function object types in the library, many predicates, 
>many
>> transformations.
>> 
>> (3) Stateful but with changeable state, eg RNGs, accumulators.
>> 
>> In my experience, category (1) and (2) cover most of the uses, eg 
>the
>> callback examples cited, predicates, etc would fall into these
>> categories, hence no need for synchronisation. Category (3) is the
>> minority category, IME, and it is only category (3) that definitely
>> requires synchronisation.
>
>No matter what you experience, (3) is a large enough category to need 
>addressing.  For some applications it's a very large category, maybe 
>even the only category.  You can't dismiss it as a corner case just 
>because of your experience.

Sorry, I didn't realise that my emails were so open to misinterpretation
so frequently! From what I can tell, I think much of our discussion has
come from this :-}

Let me summarise: (1) and (2) cover most cases, (3) is significant but a
minority. This means that although one could make a case for requiring
immutability based on majority rule, it would be too restrictive because
it would foreclose, unreasonably, the possible use of (3). This is what
I meant in an earlier posting as being too restrictive, and hence why I
felt it an unreasonable design.

>> >No, lock-free synchronization doesn't appear to be an option here, 
>> >unless you've got some technique in mind that I've not seen.
>> 
>> Lock-free and no-synchronisation are both options. I'm not sure 
>what you
>> are not seeing!
>
>As long as (3) above exists you've got problems here.

I'm still not sure what you are not seeing. Are you confusing the idea
of an option with a rule? One is optional and the other is not. For
instance, lock-free and no-synchronisation are options for (1), (2) and
(3) depending on their specifics. For the majority of cases in (3),
however, it ceases to become an option because explicit synchronisation
is definitely required. I am not sure I can put it any more clearly than
that! :-}

Kevlin
____________________________________________________________

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