Re: [boost] Boost.Signals deprecation and removal

Subject: Re: [boost] Boost.Signals deprecation and removal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-06-21 16:21:01

On 06/21/18 18:34, Zach Laine via Boost wrote:
> On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost <
> boost_at_[hidden]> wrote:
> 
>> On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <boost_at_[hidden]>
>> 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.

I can add that I did try using Boost.Signals2 in a multithreaded 
context, but ultimately its thread safety feature didn't help me as I 
had to implement external locking anyway.