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