On 11.10.2015 10:12, Noel Grandin wrote:
On 10 October 2015 at 15:41, Bjoern Michaelsen
<bjoern.michaelsen@canonical.com> wrote:
And if something like boost::signal2 is awesome beyond believe (which is --
given Michaels hint about LOCs added at least open to debate), we should first
make our least broken implementation wrap or subclass that as a migration path.
Given that we have lambda's and std::function available now, it should
be straightforward to convert our existing stuff (like tools/link.hxx)
to these without the include overhead of boost::signal
boost::signals actually has a bunch of extra features that all of the
existing observers lack, such as groups and priorities, and the question
is whether the benefit of these extra features outweighs the obvious
compile time cost of boost::signals.
in the one case where we actually (AFAICR) use the very advanced feature
of multiple observers on one signal, it was possible to limit the header
interface to just std::function (see commit
20bd0a2ee9ed899ea542c2de08efda243dbef446).
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.