Re: [sigc] How does std::function<> work with libsigc++

[Murray Cumming <murrayc murrayc com>]

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
murrayc murrayc com
www.murrayc.com
www.openismus.com