Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-30 15:54:19

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <903oa0+7kdd_at_e...>, William Kempf <sirwillard_at_my-
>> writes
> >> >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
> be surprised if you believed that the main use for function objects
> to carry modifiable state. They are a use, but I think relatively
> people believe they are the main use.

Sorry, but "main part" and "a major part" are quite different
concepts (you did say "the major part" which could be equivalent
to "main part" but that argument is pointless so I assumed you
meant "a major part"). I don't care if 75% of the usage fits your
other categories, if 25% fits the third category it MUST be addressed
accordingly in the implementation. And frankly, I think we've made a
case that for many of us it's at least close to this, if not
exceeding it. For STL algorithm usage I might reduce this to your
point of view, but, frankly, the concept being discussed here is
needed precisely because we're using it in places and for uses other
than STL algorithms. Closures are going to be a very big usage for
this concept, and closures are nearly always modified state function
> >> Function objects fall into three
> >> categories wrt state:
> >>
> >> (1) Stateless, eg functions, many of the function object types
> >the
> >> standard, many predicates, many transformations.
> >
> >Functions aren't necessarily stateless. A static or global
> >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
> >many
> >> of the other function object types in the library, many
> >many
> >> transformations.
> >>
> >> (3) Stateful but with changeable state, eg RNGs, accumulators.
> >>
> >> In my experience, category (1) and (2) cover most of the uses,
> >the
> >> callback examples cited, predicates, etc would fall into these
> >> categories, hence no need for synchronisation. Category (3) is
> >> minority category, IME, and it is only category (3) that
> >> requires synchronisation.
> >
> >No matter what you experience, (3) is a large enough category to
> >addressing. For some applications it's a very large category,
> >even the only category. You can't dismiss it as a corner case
> >because of your experience.
> Sorry, I didn't realise that my emails were so open to
> so frequently! From what I can tell, I think much of our discussion
> come from this :-}

Well, I'll take at least some blame here. When I read posts in
discussions like this I often have problems seeing other points of
view unless they are explicitly stated as different view points.
Instead I see them as criticisms of the view that I hold (which isn't
bad, it just means I misinterpret things when the track is changed
like 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
> immutability based on majority rule, it would be too restrictive
> it would foreclose, unreasonably, the possible use of (3). This is
> I meant in an earlier posting as being too restrictive, and hence
why I
> felt it an unreasonable design.

And now I'm lost. Too many messages in between these posts,
probably. The possible use of (3) causes what to be an unreasonable
design how? It _seems_ like you're agreeing with what I've been
trying to get across here with this paragraph, but then I'm not sure
why we've argued back and forth for a while ;).
> >> >No, lock-free synchronization doesn't appear to be an option
> >> >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
> 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)
> (3) depending on their specifics. For the majority of cases in (3),
> however, it ceases to become an option because explicit
> is definitely required. I am not sure I can put it any more clearly
> that! :-}

I'm not sure that there are any specifics for (3) that would allow
for lock-free and no-synchronization, other than cases where thread
boundaries aren't crossed. In any event, since (3) can't be dealt
with any where but within the implementation of the function object,
you've got the problems I've alluded to. A callback library can not
address threading issues here as long as cloning is used with out
cooperation from the wrapped function object, which is intrusive and
I'm not sure is an option here.

Bill Kempf

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