Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Callbacks and Timers » Possible improvements to U++ callbacks
Possible improvements to U++ callbacks [message #18242] Thu, 18 September 2008 19:34 Go to next message
cas_ is currently offline  cas_
Messages: 20
Registered: July 2008
Location: Poland
Promising Member
I know there are probably more urgent things to deal with (like switching to some modern graphics backend, documentation improvements and perhaps more decent debugging support on Linux), but anyway I've decided to share some thoughts.

U++ supports callbacks through Callback* family of templates. They are simple, effective and sufficient in most situations. However, there is very little support for connecting multiple functions to single callback object - only chaining is supported, as far as I know. Unfortunately, this approach makes it hard to disconnect a previously connected callback. What if you delete an object, which is pointed by a callback placed in some chain? Some existing signal/slot libraries (like libsigc++) give you even possibility to handle such situations automatically (in sigc++ it's enough to derive your class from sigc::trackable).

What do you think about improving U++ callbacks in this way? Would you find it useful? It should be possible to extend current implementation without losing backward compatibility.
Re: Possible improvements to U++ callbacks [message #18254 is a reply to message #18242] Fri, 19 September 2008 08:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cas_ wrote on Thu, 18 September 2008 13:34


What if you delete an object, which is pointed by a callback placed in some chain? Some existing signal/slot libraries (like libsigc++) give you even possibility to handle such situations automatically (in sigc++ it's enough to derive your class from sigc::trackable).



Actually, to some degree, this is possible in U++ too - see pteback family.

Quote:


What do you think about improving U++ callbacks in this way? Would you find it useful? It should be possible to extend current implementation without losing backward compatibility.



Well, I think this is a good idea, however I see very limited benefit. In fact, even the chaining is sort of redundant.

In reality, I do not remember a usecase where I would have been sorry of not having what you suggest. And simplicity is a virtue of its own Smile

Mirek
Re: Possible improvements to U++ callbacks [message #20570 is a reply to message #18254] Mon, 23 March 2009 21:43 Go to previous messageGo to next message
jlfranks is currently offline  jlfranks
Messages: 57
Registered: May 2007
Location: Houston, TX, USA
Member
Your missing Use Case:

We are using U++ callbacks as multi-cast delegates in a
publish-subscribe event message scheme.

Up until now, the subscribers were static, i.e., setup when
objects were instanced at application start-up.

We are starting on Modbus mapping of data <--> modbus
registers using multiple tree controls and callbacks
to do the heavy lifting of data I/O. This mapping is
dynamic at run-time and can be changed by the operator.

This means that the delegate must have the capability of
removing one-of-n callback functions (Subscriber) from
the callback list.

I'm not sure how to do that with PTEBACK().

Can you provide me with more insight on this?

--jlf
Re: Possible improvements to U++ callbacks [message #20580 is a reply to message #20570] Tue, 24 March 2009 12:10 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
jlfranks wrote on Mon, 23 March 2009 16:43

Your missing Use Case:

We are using U++ callbacks as multi-cast delegates in a
publish-subscribe event message scheme.

Up until now, the subscribers were static, i.e., setup when
objects were instanced at application start-up.

We are starting on Modbus mapping of data <--> modbus
registers using multiple tree controls and callbacks
to do the heavy lifting of data I/O. This mapping is
dynamic at run-time and can be changed by the operator.

This means that the delegate must have the capability of
removing one-of-n callback functions (Subscriber) from
the callback list.

I'm not sure how to do that with PTEBACK().

Can you provide me with more insight on this?

--jlf



Well, PTEBACK probably cannot really solve this issue, because it would leave Callback record intact, only made it "inactive" after destruction of pointeee.

I think that in order to correctly solve this issue, you would have to use some sort Vector<Callback> and unsubscribe command that does remove from this.

There are many possible approaches to the problem..

Mirek
Previous Topic: How can I stop the timer?
Next Topic: Problem with non-blocking mode
Goto Forum:
  


Current Time: Fri Mar 29 00:42:09 CET 2024

Total time taken to generate the page: 0.01536 seconds