On Sat, 26 Oct 2013 11:22:15 +0200 Kjell Ahlstedt <kjell.ahlst...@bredband.net> wrote: > As a result of the discussion in > https://mail.gnome.org/archives/libsigc-list/2013-July/msg00007.html > I have at last pushed a libsigc++ commit, where I explain how > std::function<> can be used in libsigc++, and why it's not that easy > to use std::bind(). > https://git.gnome.org/browse/libsigc++2/commit/?id=49e753a7e2d2ce85bc090da47b80c78a24c065d6 > > I said in July that std::function should be mentioned wherever lambda > expressions are mentioned. That's not exactly what I've done. I've > realized that std::function can be an alternative to a sigc::slot > rather than an alternative to a lambda expression.
I wouldn't say that std::function can be an "alternative" to sigc::slot: it is that sigc::slot can encapsulate any functor and therefore can wrap a std::function object. However, you would not often want to do that. You would normally pass the underlying functor that std::function might wrap (say, a lambda expression) to sigc::slot directly. As I mentioned in the correspondence to which you refer, to encapsulate the underlying functor using std::function, and then encapsulate that using sigc::slot, causes double virtual dispatch (as well as additional memory allocation). Both sigc::slot and std::function perform type erasure. It follows that I think the text "It is often possible to replace sigc::slot<> by the C++11 class std::function<>, for instance ..." is a little misleading. It is not replacing it, it is wrapping it by implicit conversion. But as I say, better to encourage people to pass the lambda expression (or whatever) directly. > As is now explained in the documentation of > sigc::signal<>::connect(), the problem with std::bind() is that it > creates a functor whose operator()() is a variadic template. > SIGC_FUNCTORS_DEDUCE_RESULT_TYPE_WITH_DECLTYPE can't deduce the > result type of such a functor. I've no idea how (or if) that can be > fixed. > > _______________________________________________ > libsigc-list mailing list > libsigc-list@gnome.org > https://mail.gnome.org/mailman/listinfo/libsigc-list _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org https://mail.gnome.org/mailman/listinfo/libsigc-list
