On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost wrote:

...

...

Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says

"deprecated status may also indicate the feature will be removed in the future."

https://en.wikipedia.org/wiki/Deprecation

That's what deprecation means in the general case, but many, many open source projects and other organizations deprecate and then never remove things. It's not reasonable for everyone to have the same expectations for deprecation. All I mean by this is please be explicit. 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. Zach

On 06/21/18 18:51, Stefan Seefeld via Boost wrote:

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.

There is a template parameter of mutex type in the `signal` template. You will still have to pay for `shared_ptr`, though.

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.

more recent benchmarks: https://github.com/NoAvailableAlias/signal-slot-benchmarks