On Thu, 22 Dec 2005 11:26:37 +0300 Vladimir Prus <ghost@cs.msu.su> wrote:
I'm not saying that it isn't useful to compare the performance of Signals against simpler models, but we need to compare apples to apples if the comparison is going to help us improve.
If by "apples to apples" you mean comparison to other signal implementation, then: 1. See comparison with Qt above 2. I don't think it's right anyway. Boost::signals has extra features compares to Boost::function and it's fair to estimate the price those features have compared to Boost::function .
Still, what do you think about some simplified boost::signal (maybe a base class, or a #ifdefed) that will have better performance?
To add (again), I think it is fair to compare boost::signal<> to boost::function<> because it gives you an idea of the extra cost. I have seen the arguments about the cost of extra functionality. However, if you are not using the extra functionality, then you should not have to pay for it. However, the Boost.Signals design/implementation requires the user to pay a performance penalty for features that MIGHT be used. This has always been my single most problem with the library. I should be able to instantiate a signal that gives me the level of functionality I desire. However, the current library mandates that simple users pay for complex and expensive features that are not used.