Hello all, been a while, I'm working on this project for a university assignment and I would really like

delegates in C++ haha, so I came up with something in a side test project and I'm pretty sure its

evil, could someone explain to me what could happen if it is in fact evil (ignoring the usual errors that could happen)

It compiles and runs correctly in visual studio 2012 without warnings

heres the code:

#include <iostream>
#include <list>

class object 
{ 
public:
	
};

struct eventargs { };

template <typename eventargs_t> struct delegate {
	typedef void (object::*type)(object*, eventargs_t*);
};

typedef delegate<eventargs>::type			eventhandler;

template <typename handler_t>
class event
{
private:
	std::list<handler_t>	_handlers;

public:
	template <typename handler_u> // I would like to see if the handler_u class is derived from 'object'
	void addhandler(handler_u handler) { _handlers.push_back((handler_t)handler); }

	template <typename handler_u> // I would like to see if the handler_u class is derived from 'object'
	void removehandler(handler_u handler) { _handlers.remove((handler_t)handler); }

	void invoke(object* sender, eventargs* args)
	{
		std::list<handler_t>::iterator it;
		for (it = _handlers.begin( ); it != _handlers.end( ); ++it)
			(sender->*(*it))(sender, args);
	}
};


class other : public object
{
public:
	void myhandler(object* sender, eventargs* args) { std::cout << "Hello World!" << std::endl; }
	void myhandler2(object* sender, eventargs* args) { std::cout << "Goodbye World!" << std::endl; }
};


int main(int, char**)
{
	object *a = new other( );
	event<eventhandler> e;
	
	e.addhandler(&other::myhandler);
	e.addhandler(&other::myhandler2);

	e.invoke(a, nullptr);
	e.removehandler(&other::myhandler);

	e.invoke(a, nullptr);

	return 0;
}

... Pretty sure its evil, but in what way?...

Just FYI I'm probably going to remove the templated parts of add/removehandler

If you have VS2012 and can install latest CTP, it adds support to variadic templates (from C++11). You can then do stuff like this:

#include <functional>
#include <iostream>
#include <list>

template<typename ... Args>
struct event {
	std::list<std::function<void (Args...)>> handlers;
	void listenIn(const std::function<void (Args...)> & handler) {
		handlers.push_back(handler);
	}
	void call(const Args ... args) {
		for (auto handler : handlers) {
			handler(args ...);
		}
	}
};

class other {
public:
	void handler1(const std::string & name) { std::cout << "Hello " << name.c_str() << "!" << std::endl; }
};

int main(int argc, char* argv[])
{
	auto a = new other();

	// this event will work with handlers having one string parameter
	event<std::string> e;

	// listen in any compatible class method
	e.listenIn(std::bind(
		&other::handler1, // class member
		a, std::placeholders::_1 // bind first param to object pointer, leave others for the event
	));

	e.call("World");

	delete a;

	return 0;
}

Basically you get type safety with no downsides, if you can ignore crap in the bind method. You can also add a lambda function as a listener:

// listen in inline lambda function
e.listenIn([] (std::string & name) { 
	std::cout << name.c_str() << " is mine." << std::endl; 
});

Several parameters example:

class other {
public:
	void handler1(const std::string & name) { std::cout << "Hello " << name.c_str() << "!" << std::endl; }
	void handler2(int number, int basket) { 
		std::cout << "There are " << number << " apples in the basket " << basket << std::endl; 
	}
};

int main(int argc, char* argv[])
{
	auto a = new other();

	// this event will work with int, int
	event<int, int> e2;

	e2.listenIn(std::bind(
		&other::handler2, // class
		a, std::placeholders::_1, std::placeholders::_2 // bind first param to object pointer, leave others for the event
	));

	e2.call(8, 2);

	delete a;

	return 0;
}

Note that adding listener in lambda function is actually safer and easier, because all the hell will break loose if the event is called after the "a" is deleted (on access to any class member).

Hello all, been a while, I'm working on this project for a university assignment and I would really like
delegates in C++ haha, so I came up with something in a side test project and I'm pretty sure its
evil, could someone explain to me what could happen if it is in fact evil (ignoring the usual errors that could happen)

Delegates per se are not evil. There are plenty of implementations out there, with various pros and cons.

Your particular implementation has a pretty nasty fault, that's also very easy to spot: The c-style cast to "handler_t". Pretty much anything can happen at that point. From compiler errors to obvious runtime errors to subtle runtime errors.

As a general rule, when programming C++, stick to static_cast and dynamic_cast. When interfacing with legacy code or low level, use reinterpret_cast and const_cast. Never ever use c-style cast, especially if you only put it in there to shut the compiler up.

This is my preferred way to doing delegates in C++, using function objects (std::function, boost::function or roll-your-own). It's definitely the least intrusive pattern I've found and I use it extensively in my GUI system. It's silly to have to define a new class just to receive events for another... This design keeps both engine and user code clean, simple, and relatively efficient.

class ButtonDelegate
{
    public:
    
    Function<void ( Button& )> press;
    Function<void ( Button& )> release;
    void* userData; // optional, could use boost::any or similar
}

void press( Button& button )
{
}

void release( Button& button )
{
}

void main()
{
    Button* b = new Button();
    
    ButtonDelegate delegate;
    delegate.press = press;
    delegate.release = release;
    
    b->setDelegate( delegate ); // could potentially have more than one delegate object if you want
}

// Button.cpp

void Button:: handlePress()
{
    if ( delegate.press )
        delegate.press( *this );
}