Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-01 09:56:36

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <906epr+6d3a_at_e...>, 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.

Not even close.  You can 3 (just to pick a number out of thin air) 
major parts to something, but you can have only one main part.  
A "main part" enjoys majority, which by very definition means only 
one.  Major does not indicate any sort of majority, only that a 
significant amount exists.

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

I'm not at all convinced you can call it a minority.
 
> >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.

Sorry, but I didn't make the suggestion, you did.  Regardless, the 
specific uses for a "callback" are for a very narrow set of reasons 
where "normal" function objects won't suffice.  These reasons are 
much more likely to increase the usage of (3), quite possibly to the 
point of majority.

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

Neither does it support lambda expressions, yet the terminology can 
still be applied.

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

Care to explain what subtle distinction you see here?

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

The binding may not be modified, but the state of the function object 
is.  This is no different than a traditional function object built to 
accumulate the results of a calculation on every member of a 
container.  The binding isn't modified there, but you put this in 
category 3.  There truly is no difference here.
 
> >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 ;->

That's cute.

> 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 don't see it that way at all.  We truly are on different wave 
lengths here.
 
> >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.

Again, these operations can not be accounted for by the library.  
They are outside the library.  They do not apply, at all, to the 
discussion at hand, to wit, can we implement a callback concept 
that's thread safe using cloning with out having intrusive 
requirements on the wrapped function objects.  (It would be a 
seperate argument about whether or not we need such a requirement 
here.)
 
> >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.

Actually, transparent sharing in this case is much less of a problem 
than deep copying.  The callback can't insure any sort of thread 
safety for the copy process when a deep copy is performed, while it 
can be insured for shallow ref-counted copies.
 
> >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?

It means that you can't gaurantee thread safe cloning of objects 
wrapped in the callback.  Now wether or not this is an issue that 
needs addressing can be quite debatable.  Why should the callback 
concept require such levels of thread safety gaurantee?  Regardless, 
though, if you're going to go down that path then the ref-counting 
approach becomes much more viable than the cloning approach.

Bill Kempf