On 06/21/18 11:34, Zach Laine via Boost wrote:
I'd like to point out that Boost.Signals2 is threadsafe, and you pay for that, to the tune of 2x slower performance than Boost.Signals. That is the figure reported during the Boost.Signals2 review. Does anyone know if this has changed? If not, removing Boost.Signals is a case of requiring some users to pay for what they do not use (the threadsafety bit). I never used signals/slots in any context in which I was signalling across thread boundaries, and I don't expect that to be a common use case.
Then that's a very good argument to parametrize Boost.Signals2 (in some way; there are many projects that use tricks to add thread safety without incurring performance overhead for the single threaded case) so you don't pay for something you don't need. I don't think that this should be an argument to keep an incompatible and deprecated API around. Stefan -- ...ich hab' noch einen Koffer in Berlin...