Prev: bind guard ?
Next: Sanity check: public/private
From: werasm on 24 Aug 2006 14:07

werasm wrote:
> kanze wrote:
> > werasm wrote:
> > > Slots are basically the callback that gets called in response
> > > to a signal (event).
> >
> > An asynchronous callback, in sum. Or a handler.
>
> Yes, asynchronous in the sense that the receiver does not know when the
> sender may make the call, but in that sense all normal functions could
> also be considered asynchronous. More importantly, the sender need not
> be bound to a particular receiver (As you know). Synchronous or
> asynchronous in the sense that the execution of the callback could be
> in the context (thread/task) of the caller or the context of the
> receiver.

This is of course not the case with signals/slots - they are always
synchronous as mentioned by another poster. I'm speaking of
possibilities here.

Also, I'm familiar with the term handler. I can see though, that it can
be ambigious. I consider the term handle and handler as two entirely
different things though.

Regards,

W


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Scott Meyers on 24 Aug 2006 15:30
Jiang wrote:
> And for callback, usually it means function pointer which
> will be passed to OS or special function (qsort ...).
> Compared with Observer, this method is ensentially
> not type safe and usually introduces tight coupling.

Your perspective on this is interesting. I agree that a callback is usually
a
function pointer and that it is often a void*, but it would never have
occurred
to me that a callback was inherently type-unsafe. Function pointers
themselves
are type-safe, so it's just the use of a void* to hold such pointer that's
not
type-safe. For example,
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Generalizing_
C-Style_Callbacks
describes the walk_tree function inside gcc, where the type of the callback
function is

typedef tree (*walk_tree_fn)(tree *, int *, void *);

This function pointer type is type-safe, though the void* parameter (used to

pass user-provided data) is not type-safe.

> Delegate solves the problems of typesafe directly event dispatching a
> nd Observer mainly decouple the one-to-many dependency.
> The functionalites overlap but they are different tools for different
> purposes. That is why we have both boost.function and boost.signal.

Can you elaborate on this? Why, for example, do we need Boost.Function?
What
functionality does it offer that Boost.Signal does not? Can't I always
replace
this,

class Widget {
public:
typedef boost::function<RetType(ParamType)> CallbackType;

explicit Widget(CallbackType f): func(f) {}
void makeCall(ParamType arg) { func(arg); }

private:
CallbackType func;
};

with this?

class Widget {
public:
typedef boost::signal<RetType(ParamType)> CallbackType;

explicit Widget(CallbackType::slot_type f) { func.connect(f); }
void makeCall(ParamType arg) { func(arg); }

private:
CallbackType func;
};

Scott

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: kanze on 25 Aug 2006 07:51
Scott Meyers wrote:
> Jiang wrote:
> > And for callback, usually it means function pointer which
> > will be passed to OS or special function (qsort ...).
> > Compared with Observer, this method is ensentially
> > not type safe and usually introduces tight coupling.

> Your perspective on this is interesting. I agree that a
> callback is usually a function pointer and that it is often a
> void*, but it would never have occurred to me that a callback
> was inherently type-unsafe. Function pointers themselves are
> type-safe, so it's just the use of a void* to hold such
> pointer that's not type-safe.

I agree. I've always considered "callback" as a more or less
generic term for inversion of control flow. The function I call
calls me back, either before returning or later. If there is a
distinction to be made, I'd say that a callback will be called
back before returning, and some other term (notification) would
be used for a deferred callback. But I think the usual usage is
to use callback for both. (Windowing systems seem to have
"callback"'s, and they are deferred.)

I agree with Jiang's observation that "handler" is probably not
very appropriate; it was just the first thing that came to my
mind (probably because in the system where I first used the
concept, we had notifications and notification handlers). He
mentionned the word "observer", which I like.

> > Delegate solves the problems of typesafe directly event
> > dispatching a nd Observer mainly decouple the one-to-many
> > dependency. The functionalites overlap but they are
> > different tools for different purposes. That is why we have
> > both boost.function and boost.signal.

> Can you elaborate on this? Why, for example, do we need
> Boost.Function? What functionality does it offer that
> Boost.Signal does not?

Or inversely, what does boost::signal offer in addition to what
boost::function offers? I'm not that familiar with
boost::signal, but a quick glance at the doc didn't reveal the
most important addition for this sort of use: the possibility of
associating a filter with the callback, so that it will only be
called in certain circumstances.

--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: kanze on 25 Aug 2006 07:58
werasm wrote:
> kanze wrote:

[...]
> > An event forwarding discriminator?

> Begging my pardon, I'm not really familiar with this term. I
> gather its from Corba - is it the mechanism that determines
> (discriminates) whereto events will be routed? In that case,
> yes.

It is, I think, a usual term in distributed systems. As you
say, Corba uses it, but I'd seen it before Corba was invented.
Basically, in the usual model that I've seen for distributed
objects, an object (consisting of attributes, and supporting
actions) notifies events: creation, deletion and attribute value
change (all state visible externally is modeled as an
attribute). In any given system (or subsystem), there will
normally be one event forwarding descriptor (although there can
be more) -- objects notify the event forwarding descriptor,
which forwards the event notification to objects (possibly---in
fact usually---on another system) which have subscribed to
notifications. The subscription request includes a scope and
filter specifying which objects and which notifications the
subscribing object is interested in. (In many ways, a
subscription resembles a LDAP request.)

--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: werasm on 25 Aug 2006 08:01

Jiang wrote:
> Hmm..., for the same reason, handler and callback should
> also be avoided.
>
> Handler is quite a general word, which can be used for
> any resouce, such as windows GDI, file, IRQ ...

Aren't you perhaps confusing HANDLE and handler, where handle refers to
the pointer (or indirection) used to access a resource. As for handler,
it is a common term used for code handling an event (The "handler" of
the event). Whether the event be generated via IRQ, or whether it be
generated via notification of some other sort - be it a callack, or
notifier, or deferred call, or command or slot, the term in general
used for handling events are called handlers (quite commonly). I can
therefore identify with the word handler when someone uses it in the
context in which it was used. I agree that we should only use it in
broader context though, and a slot is a more specific case of
"handler", so to speak.

> And for callback, usually it means function pointer which
> will be passed to OS or special function (qsort ...).
> Compared with Observer, this method is ensentially
> not type safe and usually introduces tight coupling.

Here again I disagree. I consider callback as a word describing the
broader category of similar things namely "higher level code executed
by lower level code", where callback describes the actual function that
will eventually be called. Whether the mechanism binding the "callback"
to the lower level code can be specified as typesafe or not, is a
different matter. In that sense, the function called during
notification, can also be considered a callback.

The terms callback and handler are almost (if not) synonymous. In
wikipedia's description of the two, I struggle to discern between the
two. Quote Wiki:

"In object-oriented programming languages, a call can accept an object
that implements some abstract interface, without specifying in detail
how the object should do so. The programmer who implements that object
may use the interface's methods exclusively for application-specific
code. <Such objects are effectively a bundle of callbacks>, plus the
data they need to manipulate. They are useful in implementing various
design patterns like Visitor, Observer, and Strategy."

Not that wiki is always correct (the notion of correct is subjective).

> By default, the signal/slot works in a synchronized manner, IIRC.
> The original meaning of signal does not apply here.
> That is, the emit won't return until all connected slots have returned.

True. Slots can be passed as parameters to signal, in which case they
can be asynchronous from the receivers perpective, but they are always
executed in the context of the caller.

Wrt. type-safety:
I know Qt's signal slot implementation are not typesafe (at least not
the version we are using) - if you make mistakes, things tend to
compile OK, with a little error message appearing on the command-line
when the binding/connection fails at runtime. I assume (by the looks of
it) boost.signal is typesafe.

Kind regards,

Werner


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: bind guard ?
Next: Sanity check: public/private