I've been trying to get acquainted with boost::signals.  I've done some
development with Qt, so I have used the signal/slot model, but I'm not
intimately familiar with it.

The problem I'm having, at the moment, is that the explanation (Explicitly for
Beginners) in the boost documentation seems rather confusing, to say the least.

They "begin" by introducing "an object with a slot" in the form of a struct with
an overloaded ()() operator...  How is this a "Beginner" tutorial, again?

Okay, so if you're poking around with event handling, it can be assumed you know
what overloaded operators are... maybe.  And I'll set aside my prejudices about
the use of structs, which are likely irrational anyway.

but they then proceed to create an instance of the struct, and connect it with a
signal...

Now here's my problem:  Slots are functions.  it would make more sense to me, to
start with a simple, unadorned function, and connect it with a signal.

An object, on the other hand, might have multiple slots.  It makes absolutely no
sense to me to connect an entire object -- thereby, connecting all of its slots
-- with a given signal.

So, in the interest of learning, and at the risk of looking like an idiot, I
ask: Is this actually how signals are supposed to be used, or is this a boost
peculiarity?  Am I missing something?

Regards,
A.D.B.

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> The problem I'm having, at the moment, is that the explanation (Explicitly for
> Beginners) in the boost documentation seems rather confusing, to say the least.

> They "begin" by introducing "an object with a slot" in the form of a struct with
> an overloaded ()() operator...  How is this a "Beginner" tutorial, again?

Uh... I don't think they are talking about "beginner C++ programmer"
tutorial. Rather, "beginner to Boost signals" tutorial.

If you are using a library like Boost, it can be safely assumed that you
know your way around C++ already.

Writing a functor (iow. an object that behaves like a function) should be
trivial at that point.

> And I'll set aside my prejudices about
> the use of structs, which are likely irrational anyway.

What exactly is the problem with them?

(They are used there just for brevity. You could just as well use a class
if you want. In simple cases a struct will do just fine on itself, though.)

> Now here's my problem:  Slots are functions.  it would make more sense to me, to
> start with a simple, unadorned function, and connect it with a signal.

As said, if you are using a library like Boost, one could assume you are
already fluent in C++, and that functors are as trivial to you as plain
functions.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > The problem I'm having, at the moment, is that the explanation (Explicitly for
> > Beginners) in the boost documentation seems rather confusing, to say the least.
>
> > They "begin" by introducing "an object with a slot" in the form of a struct with
> > an overloaded ()() operator...  How is this a "Beginner" tutorial, again?
>
> Uh... I don't think they are talking about "beginner C++ programmer"
> tutorial. Rather, "beginner to Boost signals" tutorial.
>
> If you are using a library like Boost, it can be safely assumed that you
> know your way around C++ already.
>

This is true.  The problem I had with it was on of unnecessary complexity.  At
least it seemed unnecessary to me.

> Writing a functor (iow. an object that behaves like a function) should be
> trivial at that point.
>
> > And I'll set aside my prejudices about
> > the use of structs, which are likely irrational anyway.
>
> What exactly is the problem with them?
>
> (They are used there just for brevity. You could just as well use a class
> if you want. In simple cases a struct will do just fine on itself, though.)
>

As I said, my problem with them is likely irrational.  I realize that they are
semantically similar to classes, but I never use them as such, or view the two
as interchangeable.


> > Now here's my problem:  Slots are functions.  it would make more sense to me, to
> > start with a simple, unadorned function, and connect it with a signal.
>
> As said, if you are using a library like Boost, one could assume you are
> already fluent in C++, and that functors are as trivial to you as plain
> functions.
>

Obviously we have different ideas of fluency.  Although I suppose that I would
call myself more conversant than fluent.  I know the grammar and syntax but not
all the nuances.

Still, it seems strange to me to bind a signal to a struct rather than to the
member function thereof.  After all, when the signal is raised/emitted, it is
the function that is called, not the containing object.

It seemed different from the way I thought I understood signals and slots,
that's all.  I have trouble with understanding this particular usage, as it
seems to be outside my experience.

A.D.B

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > > The problem I'm having, at the moment, is that the explanation (Explicitly for
> > > Beginners) in the boost documentation seems rather confusing, to say the least.
> >
> > > They "begin" by introducing "an object with a slot" in the form of a struct with
> > > an overloaded ()() operator...  How is this a "Beginner" tutorial, again?
> >
> > Uh... I don't think they are talking about "beginner C++ programmer"
> > tutorial. Rather, "beginner to Boost signals" tutorial.
> >
> > If you are using a library like Boost, it can be safely assumed that you
> > know your way around C++ already.
> >
>
> This is true.  The problem I had with it was on of unnecessary complexity.  At
> least it seemed unnecessary to me.
>
> > Writing a functor (iow. an object that behaves like a function) should be
> > trivial at that point.
> >
> > > And I'll set aside my prejudices about
> > > the use of structs, which are likely irrational anyway.
> >
> > What exactly is the problem with them?
> >
> > (They are used there just for brevity. You could just as well use a class
> > if you want. In simple cases a struct will do just fine on itself, though.)
> >
>
> As I said, my problem with them is likely irrational.  I realize that they are
> semantically similar to classes, but I never use them as such, or view the two
> as interchangeable.
>
>
> > > Now here's my problem:  Slots are functions.  it would make more sense to me, to
> > > start with a simple, unadorned function, and connect it with a signal.
> >
> > As said, if you are using a library like Boost, one could assume you are
> > already fluent in C++, and that functors are as trivial to you as plain
> > functions.
> >
>
> Obviously we have different ideas of fluency.  Although I suppose that I would
> call myself more conversant than fluent.  I know the grammar and syntax but not
> all the nuances.
>
> Still, it seems strange to me to bind a signal to a struct rather than to the
> member function thereof.  After all, when the signal is raised/emitted, it is
> the function that is called, not the containing object.
>
> It seemed different from the way I thought I understood signals and slots,
> that's all.  I have trouble with understanding this particular usage, as it
> seems to be outside my experience.
>

Though, I also don't recall my c++ instructor ever mentioning class-type
functors.  (I feel embarrassed now)

> A.D.B

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> Still, it seems strange to me to bind a signal to a struct rather than to the
> member function thereof.  After all, when the signal is raised/emitted, it is
> the function that is called, not the containing object.

You do understand what the idea with functors is?

-- 
                                                          - Warp

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> Though, I also don't recall my c++ instructor ever mentioning class-type
> functors.  (I feel embarrassed now)

structs and classes are the same thing in C++. Their only difference is
the default visibility of members, when no visibility keyword is specified.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > Though, I also don't recall my c++ instructor ever mentioning class-type
> > functors.  (I feel embarrassed now)
>
> structs and classes are the same thing in C++. Their only difference is
> the default visibility of members, when no visibility keyword is specified.
>
> --
>                                                           - Warp

I realize that. Classes are default private, structs are default public.

> > Still, it seems strange to me to bind a signal to a struct rather than to the
> > member function thereof.  After all, when the signal is raised/emitted, it is
> > the function that is called, not the containing object.
>
> You do understand what the idea with functors is?

apparently not.

When I learned about overloaded operators, I thought -- And it seems I was
wrong, or misheard -- that the parentheses were one of a few operators that it
didn't work with.  I had no idea they could even be overloaded.

The only mention of function objects in either of my textbooks was a brief
mention in relation to sorting, and an entry in a glossary.

*goes to look stuff up online.*

A.D.B.

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> > You do understand what the idea with functors is?

> apparently not.

If something takes just a function pointer, then everything it has to
work with is what it gets as parameters and nothing more. The function in
question cannot have unique data that it handles.

(You could, of course, have some static data that it handles, but that
data would be shared by all calls to that function. They cannot have
separate data for separate use cases.)

In typical C libraries this limitation is circumvented by the library
taking some void* alongside the function pointer, and passing that void*
to the function in question, which can use that pointer for whatever data
it wants. Of course this is cumbersome, not type-safe, and can be
problematic with respect to memory management. (It also adds a degree of
inefficiency that technically wouldn't be necessary if no ancillary data
is used.)

A functor, however, is not a function, but an object, and therefore it
can have its own data that it handles.

One could ask why couldn't the templates just take an object directly,
rather than a functor? It could be a convention for them to call a member
function with a certain name.

The answer is convenience and flexibility. Since calling a functor has
the exact same syntax as calling a regular function, you can give the
template either one. This avoids code repetition if you want to support
both regular functions and functors, as well as maximizes optimization
possibilities for the compiler.

As an example, you could call eg. std::sort with a comparison function
like:

    bool compareInt(int a, int b) { return a > b; }
    ...
        std::sort(v.begin(), v.end(), compareInt);

But let's say that you want to do something fancy, like for example count
how many comparisons are made during sorting. You can use a functor to do
that. For example like this:

    struct CompareInt
    {
        unsigned comparisons = 0;

        bool operator()(int a, int b) const
        {
            ++comparisons;
            return a > b;
        }
    };
    ...
        CompareInt comparator;
        std::sort(v.begin(), v.end(), comparator);
        std::cout << comparator.comparisons
                  << " comparisons were made\n";

In both cases std::sort() will internally make calls like

    if(comparator(value1, value2)) ...

If you were implementing something that uses a functor, like eg. your
own sorting algorithm, this is nice from that perspective because said
implementation doesn't need to care whether the comparator is a regular
function or a functor (or even a lambda.)

-- 
                                                          - Warp

Post a reply to this message