It's good to have a discussion on this point. We already anticipated this,
so we did some work in this area (already available in recent git
versions). We don't want to ignore the deprecation of boost.signals so this
is what we did so far:
In recent git (and in the upcoming 3.3.1 release) there's a new namespace
Wt::Signals, which imports the bits of boost.signals that we use.
While boost.signals is not really in our public API, there are bits and
pieces that shine through, so we want to keep backward compatibility in
this area. And indeed, the signals::connection object is mentioned in the
public API, so we must respect that. Wit the introduction of the
Wt::Signals namespace, our API has been rewritten in terms of
Wt::Signals::connection, but since this is the same type as
boost::signals::connection, this has no impact on backward compatibility.
Secondly, we introduced a new cmake configuration property, which allows
switching between boost.signals and boost.signals2.
WT_SIGNALS_IMPLEMENTATION can be set to boost.signals or boost.signals2. If
boost 1.54 or newer is detected, we will default to boost.signals2, for
older boosts, we will default to boost.signals. In the future (and as
suggested in this thread, but I'm not sure when and if we'll do this), we
may choose to implement our own signals library, which would then add a
third choice to this configuration setting.
With respect to the use of boost.signals2 vs boost.signals, nothing really
changed: we don't work with shared_ptr, but simply use the trackable class
to track object lifetime, just like we did before. Unless you use the
connection object, you should not notice the change from signals to
signals2.
So if you want to get rid of the warnings, use a recent version of wt. If
you require boost.signals instead of signals2 for backward compatibility
reasons, use an old boost or set WT_SIGNALS_IMPLEMENTATION manually (or use
a new boost and ignore the warnings).
In short: We do not use the thread-safety features of boost.signals2 since
we don't need them. We document to use Wt::Signals::connection instead of
boost::connection, but we keep backward-compatibility with boost.signals1.
By default we use the non-deprecated boost.signals2 on recent boost
versions to avoid the warnings. With the introduction of the Wt::Signals
namespace, we open the possibility to implement a light-weight signal/slot
library - maybe sometime.
Best regards,
Wim.
2013/8/12 Nagaev Boris <bnag...@gmail.com>
> In addition, boost::signals2 spends about 30% less memory than
> boost::signals does. This was discussed (
> http://redmine.webtoolkit.eu/issues/637 ) 2 years ago, but proposal to
> move to boost::signals2 was refused. boost::signals2 offer
> thread-safety, so it may be slower for Wt than boost::signals, because
> of locking. Thread-safety already guaranteed by Wt itself, so signals
> need not to be thread-safe. Moreover, Wt's API depends on
> boost::signals::connection. That is why move to boost::signals2 is not
> welcome. Move to C++11-smth is even worse because it would break
> compilation in old environments. I think, good libraries have the
> right to move to C++11 not before all popular Linux distributions stop
> supporting releases equipped with compilers not supporting C++11. I
> think, this will happen in 2-4 years.
>
> Regards,
> Nagaev Boris
>
>
> On Mon, Aug 12, 2013 at 5:04 AM, Alan Jesser <nigo...@hotmail.com> wrote:
> > A move to boost::signals2 would be a better option than a complete move
> to
> > C++11 functors and dropping boost::signals support. I can tell you that
> the
> > majority of the servers I deploy and build on/to are CentOS boxes. CentOS
> > won't have GCC 4.8 for a long while I'm guessing.
> >
> > Support for pre-C++11 compilers is going to have to stay around for
> awhile.
> > The enterprise world in general doesn't move to adopt the latest
> technology
> > as fast as the general public.
> >
> > Alan
> >
> > ________________________________
> > From: msherbo...@gmail.com
> > Date: Mon, 12 Aug 2013 10:35:44 +1000
> > To: witty-interest@lists.sourceforge.net
> > Subject: [Wt-interest] Plans for boost.sigals obsoletion ?
> >
> >
> > As Boost.signals is getting obsoleted bit by bit, what is the plan for
> > upgrading ?
> >
> > I know the immediate solution would be to change to boost.signals2.
> >
> > However I think a nicer solution would be to move to c++11 functors.
> >
> > Boost Signals2 offers thread safety, which is not needed right now for
> Wt.
> >
> > Functors offers a lightweight and standard way of handling signals and
> > slots. One could just keep a vector or list of functors, and that'd be
> your
> > slots; you could keep the API completely the same (probably).
> >
> > So just a thought for the consideration of the people doing the hard
> work.
> >
> > Kind Regards,
> > Matthew Sherborne
> >
> >
> ------------------------------------------------------------------------------
> > Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a
> free
> > troubleshooting tool designed for production. Get down to code-level
> detail
> > for bottlenecks, with
> > _______________________________________________ witty-interest mailing
> list
> > witty-interest@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/witty-interest
> >
> >
> ------------------------------------------------------------------------------
> > Get 100% visibility into Java/.NET code with AppDynamics Lite!
> > It's a free troubleshooting tool designed for production.
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> > _______________________________________________
> > witty-interest mailing list
> > witty-interest@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/witty-interest
> >
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
