Callback-related libraries and terminology
in [C++]
|
Prev: bind guard ?
Next: Sanity check: public/private
From: Scott Meyers on 22 Aug 2006 19:54 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 23 Aug 2006 09:19 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 23 Aug 2006 09:18 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 23 Aug 2006 09:33 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 23 Aug 2006 14:35
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! ] |