[Signals] Proposal effort for TR2
At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list: http://mail.gnome.org/mailman/listinfo/libsigc-list We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum. Doug
Doug Gregor wrote:
We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum.
You probably don't want this question here, but would thread-safety by discussed for the proposal? We couldn't use boost::signals because it wasn't thread-safe and ended-up using our own wrapper around boost::signals which made them thread-safe. Cheers Russell
On Jul 27, 2005, at 11:35 AM, Russell Hind wrote:
Doug Gregor wrote:
We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum.
You probably don't want this question here, but would thread-safety by discussed for the proposal? We couldn't use boost::signals because it wasn't thread-safe and ended-up using our own wrapper around boost::signals which made them thread-safe.
We can't write any standardese for thread safety (Standard C++ doesn't have threads... yet), but we'll try to be ensure that the interface can be implemented in a thread-safe manner and give advice for implementors regarding how to do it. Doug
Doug Gregor wrote:
At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list:
Are the TR2 discussions about signals going to be over in the libsigc++ forum ? That might imbalance the proposal in my mind toward lisigc++ rather than Boost Signals, and I hope that does not happen.
We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups)
I do not think that slot groups are bad. They provide an easy ordering mechanism for signals. I would hate to see flexibility thrown out just because the performance has not been optimized depending on whether or not any slot groups are used for any given signal.
On Jul 27, 2005, at 2:45 PM, Edward Diener wrote:
Doug Gregor wrote:
At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list:
Are the TR2 discussions about signals going to be over in the libsigc++ forum ?
Yes.
That might imbalance the proposal in my mind toward lisigc++ rather than Boost Signals, and I hope that does not happen.
Have you seen the libsigc++2 interface? libsigc++ 1.x was very different, and it's (IMHO!) poor syntax was the impetus for Boost.Signals. However, with libsigc++2, the two libraries' interfaces have practically converged already, and it's just a matter of hammering out little details.
We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups)
I do not think that slot groups are bad. They provide an easy ordering mechanism for signals. I would hate to see flexibility thrown out just because the performance has not been optimized depending on whether or not any slot groups are used for any given signal.
They require a great deal of implementation and specification complexity, which results in an inefficient (in memory and speed) data structure. Unless we can come up with a more intelligent data structure for them, I think we should keep them out of the proposal. But the libsigc++ mailing list is the better place for this :) Doug
participants (4)
-
Doug Gregor -
Douglas Gregor -
Edward Diener -
Russell Hind