Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-30 19:00:46

In message <906epr+6d3a_at_[hidden]>, William Kempf <sirwillard_at_my-
deja.com> writes
>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").  

As best I understand it, main part and major part are effectively
synonymous.

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

I think again you are misunderstanding where I'm coming from on this. I
am not dismissing them (anything but), I am simply saying that where
function objects are concerned the case you are describing is not the
majority, in other words it is a minority. It is a point of fact not a
point for debate. I merely made the point to support another point!

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

I think a broader view on function objects and their applications would
give a different perspective. Function objects can be used in many more
ways than you are suggesting -- this is on a par with limiting templates
to the idea of containers only.

>Closures are going to be a very big usage for 
>this concept, and closures are nearly always modified state function 
>objects.

I think you have to be careful with your terminology here: C++ does not
support closures. If you mean a binding between object and member
function pointer, that is a slightly different thing, although it has a
subset of closure-like properties. And because they are normally
pointers to objects, the state of the binding is not normally modified
on invocation. Hence, the state modification of such bindings is not
that common.

>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, it's the other way around: you've been agreeing with what I've been
posting, but kicking up some dust to do it ;-> Most of my previous posts
have tended to put forward multiple points of view, and then argue
through each, rejecting positions as inappropriate. It appears you have
been picking on the rejected positions or some statement in them and
arguing against the position, sometimes for the same reasons!

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

As I implied in an earlier post, an obvious case where state
modification would not cause problems and require explicit
synchronisation is where an atomic op is used, eg InterlockedIncrement
on Win32. Other cases are where objects depend in a particular way on
other objects that are already thread-safe, and therefore do not require
further synchronisation.

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

Almost: you have the problems I alluded to ;-) Which is why (3) makes
transparent sharing awkward.

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

OK, my turn: What does this mean?

Kevlin
____________________________________________________________

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