Thread: Functors as replacement for callback?

Truth is, it just depends on the situation. The key is to design things so that it doesn't matter which is used! That's where templates come in:

Code:

#include <string>
#include <iostream>

using namespace 
    std;

template < typename Logger >
class test
{
    public:

    test( Logger log )
    : log( log )
    {    
        log( "test( Logger )" );    
    }
    
    test( test const& rhs )
    : log( rhs.log )
    {    
        log( "test( test const& )" );    
    }
    
    virtual ~test( void )
    {
        log( "~test( void )" );            
    }

    Logger
        log;
};

/*
    This is a 'generator'. It simply forces the compiler to deduce 
    the exact type, without us having specify it explicitly. 
*/
template < typename Logger >
test< Logger > make_test( Logger log )
{
    return test< Logger >( log );
}

/*
    A plain vanilla logger function
*/
void just_log( char const* msg )
{
    cout << msg << endl;
}

/*
    A functor object logger
*/
class custom_embellish_log
{
    public:
    
    custom_embellish_log( string const& pre, string const& post )
    : pre( pre ), post( post )
    {    }
    
    void operator ( ) ( string const& msg )
    {
        cout << pre << msg << post << endl;
    }
    
    string
        pre, 
        post;
};

int main( void )
{
    make_test( just_log ).log( "just_log" );
    make_test( custom_embellish_log( "<[ ", " ]>" ) ).log( "custom_embellish_log" );    
}

Most importantly, we have abstracted the actual type, meaning that it's completely generic and, hence, totally reusable. The second thing, and this may not be immediately obvious, is that the actual parameter to the logging mechanism can be any type of object whatsoever - it just has to be constructible from whatever type is passed to it (in this case, our functor chose an std::string, which can be constructed with a c-style string) - making it an extremely flexible idiom.

Hth.

Thanks for your replies. The thing is, that logging example really doesn't help. In fact, it looks a lot like this article on experts exhange. Unfortunately, I'm still failing to grasp how to apply it to my particular case -- I'm sure this is going to be a *facepalm* moment the second I 'get it'. Additionally, yes, I totally get that templates will makes things a great deal easier. For the time being, I'd like to not think about templates.

In this case I'm developing a very simple GUI (basically buttons although I'd like to extend it in the future for other basic tasks). I don't need the functionality (or headaches) of the common but far too large libraries like Qt, KDE, TK and GTK+. I also didn't want to use something like Guichan because it hijacks my application.

Basically, the idea is that when the buttons clicked on (in addition to whatever other future functionality I add), they call an internal onClicked() function. The idea was to have that onClicked() function call an external function (generally from an external unrelated class) to handle whatever logic is associated with that button (say, Quit, for example). This seems fairly straight-forward with function pointers (e.g., something like typedef void (*funcPtr)(int, double) and yet I keep reading that 'function pointers are bad in C++ and should only be used for legacy code'. Yet, functors seem, to quote Bubba, kludgy and overkill for this kind of an application of them. More importantly, I still really don't understand how to translate my function pointer case like the following to functors.

Code:

class Button
{
public:
    Button(/*callback specification here*/) {}

private:
    onClicked(/* callback of sorts here */) { //call callback }

    // Some pointer to a callback function
};

class Foo
{
public:
    // I know this doesn't work
    Foo() : myButton1(this->myClickCallback), myButton2(this->myClickCallback)
    {}

private:
    Button myButton1;
    Button myButton2;

    void myClickCallback(Button &button) { // do something depending on what the button is }
}

Are there are any real benefits to using functors versus function pointers in this case? Again, to quote Bubba, most of the articles and threads (and even two books) explain either trivial cases which really don't demonstrate anything or cases which are not applicable (for example, creating unary and binary funtors to use with STL algorithms which, btw, is extremely useful).

Thanks again for everybody's help.

Originally Posted by brewbuck

EDIT: Your original example doesn't use templates, but I don't consider it a correct implementation of functors. As-is, only an object of type Functor could be used. This is the same as using no callback/functor at all. Instead you are using the term "Functor" as a fancy word for sticking some code in another class instead of writing it directly.

I figured that I was misunderstanding the whole point of functors.

From exploring this here and reading additional materials I think I'm going to go ahead and use function pointers. I'm more familiar with them anyway and, despite knowing the power of templates I still don't see how I can have a functor operate as a function pointer would or, perhaps a better way of stating it, how to properly build code around functors such that they achieve the same end result of a function pointer.

Basically, the idea is that when the buttons clicked on (in addition to whatever other future functionality I add), they call an internal onClicked() function. The idea was to have that onClicked() function call an external function (generally from an external unrelated class) to handle whatever logic is associated with that button (say, Quit, for example). This seems fairly straight-forward with function pointers (e.g., something like typedef void (*funcPtr)(int, double) and yet I keep reading that 'function pointers are bad in C++ and should only be used for legacy code'.

Think about that approach for a second. Don't you think you are handling the function information at the wrong level? In other words abstract it out by one more level and you will have a system that works. You don't need function pointers per se....you need an object that can handle calls to an object of type T for any message M where T could be an interface which has a function that can handle all calls to the object. You can actually accomplish the entire system without using function pointers at all. Who better to resolve the final function call than the object itself? No casting required and no function pointers. If you try to resolve the function calls outside of the object then you have all sorts of nasty and slow casting. Take a step back and maybe even UML your code or design and you will see at least a few ways to overcome this issue without using function pointers.

Well... the way that buttons are set up at this point... they derive from an object I call Broadcaster. Broadcasters, effectively, handle all the stuff surrounding event messages and effectively 'broadcast' events which is what the Button's listen for (clicks, in particular). When they receive certain messages (like a mouse_button_up) within their area they register that as a click and go on to call the onClicked() function which generally takes care of the rest.

The object in particular that I'm thinking of (the callee) has no business being a broadcaster but it can certainly listen for events. That would very much get the desired results I think...

brewbuck's example is exactly what I was getting at and I could not have typed out a better explanation myself. It's not the only way to solve the issue but it is one that is both effective and extendable which are two qualities that make the approach very attractive.

Thanks again for your help. I always appreciate everybody's feedback!