Re: [sigc] std::function<> and std::bind() in libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 27 Oct 2013 13:10:25 +0100
Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:
> 2013-10-26 12:54, Chris Vine skrev:
> > 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.
> You are right. if the slot will be connected to a signal, and that's 
> what you usually do with slots.
> I can change the description. How about this?
>
> *slot_base.h**, Slots*
> sigc::slot<> is similar to std::function<>. If you're going to assign 
> the resulting functor to a sigc::slot or connect it to a
> sigc::signal, it's better not to use std::function. It would become
> un unnecessary extra wrapper.
>
> Delete the new example with m_Dialog.signal_response().connect(fn).

How about, at the beginning of this block of documentation,
substituting "A Slot can be constructed from any function or function
object," for "A Slot can be constructed from any function,".

You could then probably omit the reference to a std::function object,
and perhaps substitute an example using a lambda expression.

> *slot.h, sigc::slot<>*
> sigc::slot<> is similar to std::function<>. If you're going to assign 
> the resulting functor to a sigc::slot or connect it to a
> sigc::signal, it's better not to use std::function. It would become
> un unnecessary extra wrapper.
>
> Can you come up with better descriptions?

I think this is fine but on reflection I might omit the reference to
std::function entirely.  I doubt whether many people would think of
passing a std::function object to sigc::slot.  The preceding text
states that sigc::slot can be constructed from arbitrary function
objects.  If someone were to construct a sigc::slot object from a
std::function object, they probably either know what they are doing or
really want to do it for some other reason (type erasure of the
underlying function object may already have taken place and there may be
nothing the user can do about it).

I think you are doing a great job with this documentation by the way
(and with glibmm/gtkmm).

Chris