From: Scott Meyers on
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! ]

From: werasm on

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.

Slots are basically the callback that gets called in response to a
signal (event). 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).

One thing that we are currently doing with commands, is to use it as
mechanism to communicate between various threads of execution. Our
architecture constists of various threads of execution - each thread
waiting for commands on a mailbox (this is encapsulated by what we call
a command server). Commands associated with a server execute in the
context of the server (and commands that are not, execute
synchronously) - the caller being oblivious to whether the command is
synchronous or not. This seems to simplify multithreading as the class
developer can concentrate on other things. We often use synchronous
interfaces - the implementation deciding whether to execute the call in
the context of the caller or not.

This is one aspect that I miss in boost.signals (or then, in QT signals
and slots) at this moment.

Regards,

Werner


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

From: John Moeller on
Scott Meyers wrote:
> 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?

When I briefly looked into Boost.Signals, it seemed to me to work
similarly to Qt's signal/slot mechanism. I would say that what you
have about sums it up.

> 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 would guess that the terminology comes either from Trolltech's Qt
library, or whatever origin Qt has for the terminology (that's a guess,
though). Personally, I would have chosen "receiver" instead of "slot"
to go with the broadcast-like language.

Apologies if I'm incorrect.


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

From: Kurt Stege on
Scott Meyers wrote:

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


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

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


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

From: kanze on
werasm wrote:
> 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?

> Slots are basically the callback that gets called in response
> to a signal (event).

An asynchronous callback, in sum. Or a handler.

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

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