Boost logo

Boost :

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."
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at