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
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
> >accordingly in the implementation.
> I think again you are misunderstanding where I'm coming from on
> am not dismissing them (anything but), I am simply saying that where
> function objects are concerned the case you are describing is not
> majority, in other words it is a minority. It is a point of fact
> 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
> >than STL algorithms.
> I think a broader view on function objects and their applications
> give a different perspective. Function objects can be used in many
> ways than you are suggesting -- this is on a par with limiting
> 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
> I think you have to be careful with your terminology here: C++ does
> 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
> 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
> 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
> >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
> 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
> 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
> >I'm not sure that there are any specifics for (3) that would allow
> >for lock-free and no-synchronization, other than cases where
> >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
> on Win32. Other cases are where objects depend in a particular way
> other objects that are already thread-safe, and therefore do not
> 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
> >In any event, since (3) can't be dealt
> >with any where but within the implementation of the function
> >you've got the problems I've alluded to.
> Almost: you have the problems I alluded to ;-) Which is why (3)
> 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
> >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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk