From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-01 15:21:30
--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <908e74+a1qv_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> 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.
> OK, so we are well off topic here. However, your interpretation is
> unfortunately incorrect. Etymologically it would be a
> given the varied state of the English language that is perhaps not
> compelling ;-) However, checking both US and UK dictionaries reveals
> definitions of major in terms of majority, main, principal,
> greater, and a whole host of other words that, from my
> the English language, mean similar things.
Careful here. Significant also does not denote a "majority".
Neither does greater. All that's denoted is that it's larger (in
what ever sense) then something else. Again, something may have 3
major parts, but only one of them will constitute a majority.
> >I'm not at all convinced you can call it a minority.
> That which is not the majority is, by definition, the minority (ie
> minor part). I believe there is a bit of a debate currently going
> the US on this very topic ;-)
We can argue language semantics until the cows come home. It doesn't
change my stance or my view point. I also think you can see where
I'm coming from, so I refuse to nit-pick stuff like this to death.
> >Sorry, but I didn't make the suggestion, you did. Regardless, the
> >specific uses for a "callback" are for a very narrow set of
> >where "normal" function objects won't suffice. These reasons are
> >much more likely to increase the usage of (3), quite possibly to
> >point of majority.
> This all sounds remarkably hypothetical, and contrary to both common
> theory and practice.
An authoritative statement with no substance. Not very helpful one
way or another in this thread.
> >> I think you have to be careful with your terminology here: C++
> >> support closures.
> >Neither does it support lambda expressions, yet the terminology
> >still be applied.
> Sure, we can all apply terminology loosely, the question is to what
> effect? In the case of the Lambda Library it is to good effect. In
> case of closures, I believe not.
> >> If you mean a binding between object and member
> >> function pointer, that is a slightly different thing, although
> >has a
> >> subset of closure-like properties.
> >Care to explain what subtle distinction you see here?
> A binding of an object pointer and member function pointer is a
> case of an expression bound to a calling context. If you have
> in languages that have support for closures you will appreciate
> distinction is not subtle.
No, but the reasoning for you to nit pick here is quite subtle. What
I describe most certainly is a closure. It just doesn't encompass
the full set of uses of the term. I see no reason for your argument
in my use of the term here, especially since I qualified what I meant
in my description.
> >The binding may not be modified, but the state of the function
> >is. This is no different than a traditional function object built
> >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.
> There truly is. Some of the commonest such bindings, eg event-based
> callbacks, use pointers rather than objects by value.
This makes little difference. So the modification of the state is
indirect instead of direct for some cases, this doesn't eliminate the
> >> Most of my previous posts
> >> have tended to put forward multiple points of view, and then
> >> through each, rejecting positions as inappropriate. It appears
> >> been picking on the rejected positions or some statement in them
> >> 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 can only speak for myself, but my own inclination is to try to
> towards consensus rather than contradiction.
That would be the inclination of any sane person so I'm willing to
bet that's what we're all doing here. Do you honestly think other
> >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,
> Surely you are contradicting yourself? These operations are as
> to the discussion as threads, which are also not supported in the
> library. Sure, if you don't want to discuss threading any further
> OK, but I happen to regard it, and other facilities associated with
> as quite important.
No, I'm not contradicting myself. This is clear in the remainder of
the quote you split here...
> >to wit, can we implement a callback concept
> >that's thread safe using cloning with out having intrusive
> >requirements on the wrapped function objects.
> Is this a question or a statement? If it's a statement (ie "we
> then I am in agreement (because that was what I posted what seems
> long time ago). If it's a question, then the answer is yes.
No, the answer is not yes. *shakes head* Sorry, but at this point
I'm stuck just arguing in circles because we've got an obvious
disconnect in communication that I can't see how to get around. Read
what I've said in previous posts again to try and see my point.
> >Actually, transparent sharing in this case is much less of a
> >than deep copying. The callback can't insure any sort of thread
> >safety for the copy process when a deep copy is performed, while
> >can be insured for shallow ref-counted copies.
> I believe you have this back to front. Perhaps you would like to
> demonstrate what you are thinking with a code fragment -- English
> not seem to be serving us well ;->
A deep copy requires copying of all state that may be contained
within a function object. This copying of state must be thread safe
in order for the copying of the function object to be thread safe.
These state objects are not a part of the function object library,
but are data types created by the programmer outside of the library.
Thus the library can not gaurantee that copy of these state objects
is thread safe. Thus the library can not gaurantee that copying the
function object is thread safe.
A ref-counted function object doesn't do a deep copy, so it can
gaurantee that copying the function object is thread safe (it only
needs to insure that the ref-count and the wrapped function object
pointer are handled in a thread safe manner).
This path of arguing would thus lead us to a ref-counted
implementation instead of a cloning implemtation. However, I don't
think that's the right answer. First, nothing says that we must (or
even should) gaurantee thread safety here. Second, I believe in one
of the arguments that's been brought up, and that you've agreed with
as well, to wit such functionality can be built on top of a concept
that uses cloning. So, I believe we should stick with the basic
concept, i.e. cloning, and build anything else required on top of
Bringing thread safety into this discussion is only partially
appropriate (we must insure that thread safety can be achieved at
some level of abstraction in the implementation of the concept).
Doing so, and making it the sole goal as has seemed to be the case in
this thread, leads me to a different conclusion from the one you're
trying to make.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk