 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Scott Meyers
Guest
|
 Posted: Wed Aug 23, 2006 4:54 am Post subject: Callback-related libraries and terminology |
 |
|
I've been trying to make sense of Boost.Signals, especially in terms of
some other libraries I'm familiar with. Part of the problem is
terminology, I think, e.g., callbacks, slots, and delegates (as in .NET,
but also as used by some for bound member function pointers
(e.g.,http://www.codeproject.com/cpp/FastDelegate.asp)). I'm hoping people
will take a look at what follows, correct any errors they see, and maybe
lend additional insight so that my understanding will be improved.
We start with "callable entities" -- things that can be called, e.g.,
function pointers, function objects, bound member functions, etc. As I
understand it:
- A callback (function or object) is a callable entity
- A slot in Boost.Signals is a callable entity
- tr1::bind and boost::lambda create callable entities.
- A tr1::function object stores a callable entity.
We also have collections of callable entities:
- A .NET delegate is a collection of 0 or more callable entities with a
given signature.
- A signal in Boost.Signals is a collection of 0 or more callable
entities with signatures compatible with a given signature.
Objects of these collection types are also callable entities:
- When a Boost.Signals signal or a .NET delegate is called, it invokes
the callable entities it contains.
Is that correct?
Also, does anybody know where the name "slot" comes from in this context?
I've found this term to be a stumbling block for trying to understand this
stuff.
Thanks,
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Kurt Stege
Guest
|
| Posted: Wed Aug 23, 2006 6:33 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Scott Meyers wrote:
| Quote: | We start with "callable entities" -- things that can be called, e.g.,
function pointers, function objects, bound member functions, etc.
|
This seems to be a reasonable universal definition. However,
in some context it might be useful to treat only a special
subset of "callable entities", e.g. "slots".
For example, this universal definition would tell foo as
callable entity:
struct bar { void func(); };
bar foo;
For the object foo can be called by writing foo.func();
You are both writing about general understanding and specific
about boost.signals. I don't know boost.signals good enough
to know if in the language of Boost foo is a callable entity
or not (for foo(); is not valid).
| Quote: | As I
understand it:
- A callback (function or object) is a callable entity
- A slot in Boost.Signals is a callable entity
- tr1::bind and boost::lambda create callable entities.
- A tr1::function object stores a callable entity.
|
I guess so, yes ...
| Quote: | We also have collections of callable entities:
- A .NET delegate is a collection of 0 or more callable entities with
a
given signature.
- A signal in Boost.Signals is a collection of 0 or more callable
entities with signatures compatible with a given signature.
Objects of these collection types are also callable entities ...
|
Using my "universal" understanding of the term: yes.
When Boost uses a narrower understanding (like: callable by
putting brackets () behind the name of the entity): probably yes.
However, there might be "collections of callable entities"
that are not callable entities by them self, for example
std::list<struct bar>. (Assuming that by now struct bar has
an operator().)
| Quote: | Also, does anybody know where the name "slot" comes from in this context?
|
slot is the matching part for signal, like "key" and "lock".
The first time I have heard of "signal" and "slot" is the
Qt library from Trolltech.
The signal slot concept takes a subset of the "universal"
callable entity, and calls objects of this subset a slot.
Then it defines a special subset of "collection of callable
entities", most often a special type of collection of slots,
and calls this collection a "signal".
Using these (implementation specific) terms of slots and
signals, you can create components (or modules or whatever
you like to call such things). These components are connected
(using some kind of "wires" between the signals and slots)
to larger more complex components.
The original idea uses not any "callable entities" but
"special callable entities" called slots. From that idea
the term "slot" is coming. A signal is put into a slot like
a plug is put into a socket.
Nowadays, using C++ templates and generic programming,
the signal slot libraries try to use any callable entities
instead of something that is specially crafted for slots.
From my page at http://www.goto.onlinehome.de/sigslot/sigslot.html
I have copied this list of references for signal slot libraries
that I am aware of.
[Gregor2004]: Douglas Gregor
"Boost.Signals"
http://www.boost.org/doc/html/signals.html
This article discusses the signal implementation that is part of the
Boost libraries.
[Hickey1994]: Rich Hickey
"Callbacks in C++ Using Template Functors"
http://www.tutok.sk/fastgl/callback.html
This old article describes a technical solution to call any member
function from a signal.
[Thompson2002]: Sarah Thompson
"sigslot - C++ Signal/Slot Library"
http://sigslot.sourceforge.net/sigslot.pdf
http://sigslot.sourceforge.net/
A typical signal-slot implementation using C++ templates.
[TTL2005]: Eugene
"Tiny Template Library"
http://sourceforge.net/projects/tinytl
Template libraries that include a lightweight signal slot implementation
similar to the boost technology.
[QT]
Hope that helps,
Kurt.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Wed Aug 23, 2006 11:35 pm Post subject: Re: Callback-related libraries and terminology |
|
|
werasm wrote:
| Quote: | Scott Meyers wrote:
Also, does anybody know where the name "slot" comes from in
this context? I've found this term to be a stumbling block
for trying to understand this stuff.
I think the name "slot" originates from the Qt GUI Framework.
They used a signal-slot mechanism to interface to events that
the client of a widget needed to respond too. Similarly to
Borland's Closures.
This snippet is from their documentation:
"In Qt we have an alternative to the callback technique. We use signals
and slots. A signal is emitted when a particular event occurs. Qt's
widgets have many pre-defined signals, but we can always subclass to
add our own. A slot is a function that is called in reponse to a
particular signal. Qt's widgets have many pre-defined slots, but it is
common practice to add your own slots so that you can handle the
signals that you are interested in."
I would define the signal as the "callable entity" and the
slot as the "executable entity". The lost exists at the
execution sight, whereas the signal exists at the callsight.
|
I would avoid the word "signal", as it has other meanings in C++
(and C). What's wrong with the classic terms event or notifier,
and handler or callback?
| Quote: | Slots are basically the callback that gets called in response
to a signal (event).
|
An asynchronous callback, in sum. Or a handler.
| Quote: | The mechanism IM(h)O is very similar to GOFS command pattern
which I personally prefer at this moment. A signal is emitted,
and all slots bounded to that signal is called, so to speak
(Macro-command is executed, and all the children bounded to it
is executed).
|
An event forwarding discriminator?
--
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! ] |
|
| Back to top |
|
|
Kurt Stege
Guest
|
| Posted: Thu Aug 24, 2006 6:35 pm Post subject: Re: Callback-related libraries and terminology |
|
|
kanze wrote:
| Quote: | werasm wrote:
Scott Meyers wrote:
Also, does anybody know where the name "slot" comes from in
this context?
I think the name "slot" originates from the Qt GUI Framework.
I would define the signal as the "callable entity" and the
slot as the "executable entity". The lost exists at the
execution sight, whereas the signal exists at the callsight.
I would avoid the word "signal", as it has other meanings in C++
(and C). What's wrong with the classic terms event or notifier,
and handler or callback?
|
"Handler" is a worthless term. What is the handler handling?
Signals? Events? Messages? Fruits?
"Callback" is misleading. The word (and the classic meaning)
says: I am calling you now. Please do you call _me_ back
sometimes later.
The callback idea separates the sender and the receiver of
a message in a way that the sender (at compile time) does
not know anything about the receiver. However, the receiver
knows about the sender for registration purpose.
The signal slot idea separates registration from the receiver.
The receiver does not have to know anything about the sender,
neither in compile time nor in run time. This separation helps
to re-use the receiver for other application contexts, just by
exchanging the "application" that does the registration (often
called "connection" between sender and receiver).
| Quote: | Slots are basically the callback that gets called in response
to a signal (event).
An asynchronous callback, in sum. Or a handler.
|
See about the term "handler"? You like to name the signal a
handler, and now you are naming the slot a handler.
I didn't find short and pregnant replacements for the terms
signal and slot. Message sender or event receiver might do,
but they sound clumsy. I suppose the terms signal and slot
are used in a wide area for exactly this purpose, that the
danger of confusion with Unix- or C-signals is small.
Best regards,
Kurt.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
werasm
Guest
|
| Posted: Thu Aug 24, 2006 11:07 pm Post subject: Re: Callback-related libraries and terminology |
|
|
werasm wrote:
| Quote: | 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! ] |
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Fri Aug 25, 2006 12:30 am Post subject: Re: Callback-related libraries and terminology |
|
|
Jiang wrote:
| Quote: | 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.
| Quote: | 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! ] |
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Sun Aug 27, 2006 5:34 pm Post subject: Re: Callback-related libraries and terminology |
|
|
kanze wrote:
| Quote: | 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.
|
I'm no expert, but AFAIK, Boost.Signal has no such functionality. Unlike
Boost.Function (and tr1::function), however, it is possible to "connect"
multiple functions (actually callable entities) to a single signal,
which is why
I have this notion that a Boost signal can be thought of as a
"container" of
callbacks.
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Sun Aug 27, 2006 5:36 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Jiang wrote:
| Quote: | Well, I think we need Boost.Function because:
1. The old style callback mechanism is not type safe.
|
But slots in Boost.Signal are typesafe and can, I believe, replace
Boost.Function objects in most contexts.
| Quote: | 2. We can control the return type and function signature in a
systematical manner.
|
Ditto.
| Quote: | 3. We can use both free and member functions with it.
|
Ditto.
| Quote: | 4. We can check empty target call.
|
Boost.Signals offers the "empty" and "num_slots" member functions for this.
Note how this makes a signal look syntactically like a container.
| Quote: | 1. Signal is non-copyable, but copy and assignment are
available for Function.
|
I didn't realize this, thanks for pointing it out. The lack of these
functions
makes Boost.Signal look less like a container.
| Quote: | 3. Compared with Boost.Signal, it is slightly fast
and memory friendly.
|
Can you give me an overview? I have a vague idea of the implementation of
Boost.Function, my guess would be that a Boost.Signal would be
implemented as,
um, a collection of Boost.Functions :-)
| Quote: | But, the above replacement does not show me why
Boost.Function should be replaced with Boost.Signal.
|
I'm not suggesting that Boost.Function should be replaced, I'm just
trying to
better understand the differences. C++ has both arrays and single
objects, even
though an array of size 1 could be used in place of single objects.
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Hendrik Schober
Guest
|
| Posted: Mon Aug 28, 2006 9:21 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Scott Meyers <usenet (AT) aristeia (DOT) com> wrote:
| Quote: | 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
| Quote: | 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.
|
IME that's (almost) always the case if you use functions.
You need to provide some data for context to the callback.
As what data is needed isn't known by the function calling
the callback, a generic type is needed. I see only three
choices for this: Passing around 'void*', making the
function that calls the callback a template, or using
(polymorphic) function objects.
Using 'void*' is type-unsafe. That leaves templates and
polymorphism. Since I can't turn every function into a
template that takes a callback, polymorphism seems to be
to the general solution to me.
Schobi
--
SpamTrap (AT) gmx (DOT) de is never read
I'm Schobi at suespammers dot org
"The sarcasm is mightier than the sword."
Eric Jarvis
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Mon Aug 28, 2006 9:26 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Scott Meyers wrote:
| Quote: | Jiang wrote:
Well, I think we need Boost.Function because:
1. The old style callback mechanism is not type safe.
But slots in Boost.Signal are typesafe and can, I believe, replace
Boost.Function objects in most contexts.
2. We can control the return type and function signature in a
systematical manner.
Ditto.
3. We can use both free and member functions with it.
Ditto.
4. We can check empty target call.
Boost.Signals offers the "empty" and "num_slots" member functions for
this.
Note how this makes a signal look syntactically like a container.
|
Yes, Boost.Singals can replace Boost.Function most of the time,
my list was intended to compare Boost.Function with old style
callbacks.
| Quote: | 1. Signal is non-copyable, but copy and assignment are
available for Function.
I didn't realize this, thanks for pointing it out. The lack of these
functions
makes Boost.Signal look less like a container.
|
Well, actually the Solt part of the Boost.Signals is just a
container which manages a list of function objects. And
iterator based on quite a few iterator adaptors is available
for iterating through the connected function objects in the
container. The function objects are copyable, but Signals
itself is noncopyable since the the connected slots are
connected to signal, not the data member contained by
signal object ( sorry for the wording here ).
| Quote: | 3. Compared with Boost.Signal, it is slightly fast
and memory friendly.
Can you give me an overview? I have a vague idea of the implementation of
Boost.Function, my guess would be that a Boost.Signal would be
implemented as,
um, a collection of Boost.Functions :-)
|
Well, as you know, the Boost.Function is a quite small
wrapper. It contains only two function pointers
(invoker+manager) and one function pointer or data pointer.
Also the dispatching through function pointer is very fast.
Benchmark data is available at:
http://www.boost.org/doc/html/function/faq.html#id2699504
However, the Boost.Signals asks more because it must
manage the both the Signal and Slot(iterator), and the
connection between them. Although the basic_connection
holds several pointer members, and trackable must track
all connections, I do not think memory space is really an
issue.
| Quote: | But, the above replacement does not show me why
Boost.Function should be replaced with Boost.Signal.
I'm not suggesting that Boost.Function should be replaced, I'm just
trying to
better understand the differences. C++ has both arrays and single
objects, even
though an array of size 1 could be used in place of single objects.
|
Exactly, I failed to find such a good example. :-)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Chris Vine
Guest
|
| Posted: Tue Aug 29, 2006 3:05 am Post subject: Re: Callback-related libraries and terminology |
|
|
Kurt Stege wrote:
The signal/slot library I generally use is libsigc++ at
http://libsigc.sourceforge.net/ .
Version 2.0 is not dissimilar to the boost signal library.
Chris
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Scott Meyers
Guest
|
| Posted: Tue Aug 29, 2006 8:37 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Jiang wrote:
| Quote: | Well, actually the Solt part of the Boost.Signals is just a
container which manages a list of function objects.
|
You mean the signal here, not the slot, right? It's the signal that's a
container, not the slot.
| Quote: | Well, as you know, the Boost.Function is a quite small
wrapper. It contains only two function pointers
(invoker+manager) and one function pointer or data pointer.
|
Yes, but it also uses heap memory. So the total memory used by a
boost::function object is more than just sizeof(boost::function<signature>).
This is very important for some kinds of applications.
| Quote: | Also the dispatching through function pointer is very fast.
|
It all depends on what you're comparing it to. In recent tests I've run, I've
found invocation through a boost::function to be substantially slower than via a
virtual call or a "delegate" (e.g., as in Don Clugston's FastDelegates library).
I'm going to start a separate thread on this when I have time, because I was
really surprised to find that invocation via boost::function was 2-3x slower
than a virtual or delegate call. Currently, I'm hoping I did something stupid
in my tests and that my data is invalid. (Yes, I compiled in release mode with
full optimizations, but that doesn't mean I didn't do something else that's
stupid, e.g., compare apples and oranges.)
Scott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Douglas Gregor
Guest
|
| Posted: Sat Sep 02, 2006 8:14 pm Post subject: Re: Callback-related libraries and terminology |
|
|
Scott Meyers wrote:
| Quote: | Jiang wrote:
Well, as you know, the Boost.Function is a quite small
wrapper. It contains only two function pointers
(invoker+manager) and one function pointer or data pointer.
Yes, but it also uses heap memory. So the total memory used by a
boost::function object is more than just sizeof(boost::function<signature>).
This is very important for some kinds of applications.
|
Yes, and the cost of heap allocation when copying boost::function (or
tr1::function) objects can also be costly in some applications. The
latest boost::function (to be a part of Boost 1.34.0) uses a small
buffer optimization to reduce the need for heap allocation,
particularly in the common case where something like "bind(&X::f, &f,
_1, _2, _3)" is placed into a boost::function.
| Quote: | Also the dispatching through function pointer is very fast.
It all depends on what you're comparing it to. In recent tests I've run, I've
found invocation through a boost::function to be substantially slower than via a
virtual call or a "delegate" (e.g., as in Don Clugston's FastDelegates library).
I'm going to start a separate thread on this when I have time, because I was
really surprised to find that invocation via boost::function was 2-3x slower
than a virtual or delegate call.
Currently, I'm hoping I did something stupid
in my tests and that my data is invalid. (Yes, I compiled in release mode with
full optimizations, but that doesn't mean I didn't do something else that's
stupid, e.g., compare apples and oranges.)
|
What are you putting into the boost::function? Function objects? Member
pointers? Function pointers? boost::function adds one level of
indirection to whatever you put in there, so if you're comparing a
boost::function calling through a function pointer against calling
through the function pointer itself, expect a 2x difference because
boost::function needs to perform two indirect calls through function
pointers.
Cheers,
Doug
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
