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
