On Fri, 2013-07-26 at 16:25 +0200, Kjell Ahlstedt wrote:
> std::function<> is a functor (function object). Not much more than > that is required in order to convert it to a sigc::slot. What is > required, is that the compiler must be able to check that the return > type is correct. That's described at > https://developer.gnome.org/libsigc > ++/unstable/group__sigcfunctors.html > > Your example works because the return type is void. That's some kind > of default assumption in libsigc++. std::function<>s with other return > types work only if you include namespace sigc > { SIGC_FUNCTORS_DEDUCE_RESULT_TYPE_WITH_DECLTYPE } in your code. I guess that we should maybe emphasize the C++11 function<> case in that list of alternative ways to make things work. > sigc::trackable derived objects don't get any special treatment, if > they are included in std::function or a C++11 lambda expression. > Therefore I added sigc::track_obj(), but it has not yet made it into a > libsigc++ release. So sigc::track_obj() creates a sigc::slot<> from a C++11 function<> or a C++11 lambda? Wouldn't it be cleaner to just (or also) add a specific connect(std::function<>) method overload that did this automatically? > There has been some discussion about libsigc++ and C++11 lambda > expressions over the last two years or so. I think most of what has > been said about C++11 lambda expressions can be directly translated to > std::function. I wonder if we could ever deprecate sigc::slot<>, at least as public API. I don't much like the new syntax compared to sigc::mem_fun(), but we should expect people to want to use sigc::function<> now that it is officially part of C++. And we could always leave sigc::mem_fun() as a convenient way to create a std::function<>. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org https://mail.gnome.org/mailman/listinfo/libsigc-list
