О вольностях в ссылках или простейший обмен сообщениями

Обмен сообщениями достаточно фундаментальная вещь ^[1] в науке Computer Science. Будем рассматривать её в приближении к событийно-ориентированному программированию (event-driven ^[2]). Терминология, возможности и реализации могут отличаться: события (events), сообщения (messages), сигналы/слоты (signals/slots) и callbacks. В целом суть, что с приходом события запускается ответная реакция.
Сама система обмена сообщениями в статье послужила демонстрацией вольной, но допустимой интерпретации ссылок/указателей, упрощающей код. Получившаяся система тривиальна и умеет только регистрировать обработчик на определённый код сообщения и посылать сообщения с таким кодом.
Допустим что обработчики нетривиальные, а сообщений немного. И что мы сами генерируем сообщения и они не приходят нам по сети, например. В таком случае хочется иметь что-то более удобное с явными объявлениями переменных в сообщении. Например, нечто подобное:

StringMessage* str_message = ...;
send(my_message);
...
void handle_message(const Message* message) {
	assert(message);
	const StringMessage* str_message = dynamic_cast<const StringMessage*>(message);
	assert(str_message);
	std::cout << str_message->message ...
}

Но хочется убрать проверочный код, не имеющий отношения к логике работы, под капот. Заменим поэтому указатель на ссылку, показав что в обработчик точно приходит объект, а не NULL nullptr. И пусть обработчик сразу принимает требуемый им тип сообщения.

void handle_message(const StringMessage& message) {
	...
}

Как осуществить задуманное и поддержать другие возможные классы сообщений?

Идея проста. Во время регистрации обработчика узнаем тип аргумента, который он принимает и запишем его. А при отсылке сообщения проверим, что тип сообщения совпадает с типом аргумента обработчика. Для каждого нового типа сообщения пронаследуемся от базового класса сообщения Message.

class Message{
public:
	Message(unsigned code) : code(code) {}
	virtual ~Message() {}
	const unsigned code;
};

enum Code {
	STRING = 1
};

class StringMessage : public Message {
public:
	StringMessage(const std::string& msg) : Message(STRING), message(msg) {}
	const std::string message;
};

Решение с делегатами

Старые добрые делегаты работают в С++03. Один из примеров реализации описан на Хабре здесь ^[3]. Делегаты в данном случае это только функциональная обёртка над функциями-членами. Так выглядит подписка обработчика.

class Messenger {
	...
	template <class T, class MessageDerived>
	void subscribe(int code, T* object, void (T::* method)(const MessageDerived&)) {
		// Сохраняем тип аргумента, который действительно принимает функция-член класса
		const std::type_index& arg_type = typeid(const MessageDerived);
	
		// Преобразуем указатель функцию, как будто он принимает просто (const Message&)
		void (T::* sign)(const Message&) = (void (T::*)(const MessageDerived&)) method;
				
		// Добавляем нового подписчика
		subscribers_.push_back(Subscriber(code, object, NewDelegate(object, sign), arg_type));
	}
}

Корректность. Как только устройство производного класса сообщения становится менее тривиальным, появляется проблема среза объектов ^[4]. При входе в метод send объект срезается до базового типа, сдвинув передаваемую ссылку на базовый объект. Обработчик не узнает об этом и воспользуется невалидной ссылкой. Проинформируем, если нам встретится такой объект.

template <class Base, class Derived>
bool is_sliced(const Derived* der) {
	return (void*) der != (const Base*) der;
}

Но лучше всего написать проверку времени компиляции. Компилятор сделает срез базового типа по отнаследованному. И если указатель увеличился с 1, значит объект был срезан.

template <class Base, class Derived>
struct is_sliced2 : public std::integral_constant<bool, 
	((void*)((Base*)((Derived*) 1))) != (void*)1> {};
...
static_assert(!is_sliced2<Message, Arg>::value, "Message object should not be sliced");

К сожалению, компилятор MSVS 2013 не справляется с компиляцией условия, но gcc-4.8.1 вполне ^[5].

Отправление сообщения делаем просто. Проверяем, что сообщение не срезается. Пробегаем по всем обработчикам. Если коды сообщения и обработчика совпадают, то проверяем типы на соответствие. Если всё совпало, то вызываем обработчик.

class Messenger {
	...
	template <class LikeMessage>
	void send(const LikeMessage& msg) {
		assert((!is_sliced<Message, LikeMessage>(&msg)));
		send_impl(msg);
	}

private:
	void send_impl(const Message& msg) {
		const std::type_info& arg = typeid(msg); // Кешируем настоящий тип сообщения
		for (SubscribersCI i = subscribers_.begin(); i != subscribers_.end(); ++i) {
			if (i->code == msg.code) {           // Нашли требуемый код
				if (arg != i->arg_type)          // Плохо, если не совпали типы аргумента и делегата
					throw std::logic_error("Bad message cast");
				i->method->call(msg);            // Вызывается ф-я член 
			}
		}
	}
}

Важно не забыть добавить проверку, что MessageDerived действительно унаследован от Message. В С++11 в файле <type_traits> есть std::is_base_of. В С++03 проверку времени компиляции придётся писать руками.
Пример с делегатом простой. Класс обработчика, подписка делегата и отправление сообщения:

class Printer {
public:
	void print(const StringMessage& msg) {
		std::cout << "Printer received: " << msg.message << std::endl;
	}
};

int main() {
	Messenger messenger;
	Printer print;
	messenger.subscribe(STRING, &print, &Printer::print);
	messenger.send(StringMessage("Hello, messages!"));
	return 0;
}

Код с делегатами ^[6]

C++11

В C++11 появились лямбды. Наша цель, чтобы процесс подписки выглядел очень просто:

messenger.subscribe(STRING, [](const StringMessage& msg) {...});

Лямбду можно обернуть в std::function, но для этого нужно знать тип лямбды, не потеряв тип входного аргумента. А затем сконвертировать лямбду во что-то универсальное вроде std::function<void (const Message&)>. Но нельзя просто так взять и узнать тип С++ лямбды.

template <typename Function>
struct function_traits
	: public function_traits<decltype(&Function::operator())> {};

template <typename ClassType, typename ReturnType, typename... Args>
struct function_traits<ReturnType(ClassType::*)(Args...) const> {
	typedef ReturnType (*pointer)(Args...);
	typedef std::function<ReturnType(Args...)> function;
};

Код по смыслу аналогичен варианту с делегатами. Усложняется лишь логика работы с лямбдой.

template <typename Function>
class Messenger {
	...
	void subscribe(int code, Function func) {
		// Узнаем тип функции с помощью function_traits
		typedef typename function_traits<Function>::function FType;

		// У std::function есть синоним аргумента argument_type (если аргумент единственный) 
		typedef typename FType::argument_type Arg;
		
		// Сохраним typeid аргумента
		auto& arg_type = typeid(Arg);
			
		// Проверим, что сообщение пронаследовано от Message
		// Тип Arg является ссылкой. Для проверки типа, ссылку нужно убрать из типа.
		typedef std::remove_reference<Arg>::type ArgNoRef;
		
		// Проверка на наследственность
		static_assert(std::is_base_of<Message, ArgNoRef>::value, 
			"Argument type not derived from base Message");

		// Преобразуем лямбду в соответствующий ей указатель на функцию
		auto ptr = to_function_pointer(func);

		// И тут же меняем на нужный тип указателя, который и сохраняем
		auto pass = (void(*) (const Message&)) ptr; 
		
		subscribers_.emplace_back(std::move(Subscriber(code, pass, arg_type)));
	}
}

template <typename Function>
typename function_traits<Function>::pointer
to_function_pointer(Function& lambda) {
	return static_cast<typename function_traits<Function>::pointer>(lambda);
}

std::function<void (const Message&)>       msg_func = ...;
std::function<void (const StringMessage&)> str_func = msg_func; // И всё

Код отправки почти дословно повторяет разобранный код с делегатами. Весь код с лямбдами ^[8].
Вот финал нашего труда. Можно просто зарегистрироваться, послать сообщение и обработать его.

int main() {
	Messenger messenger;
	messenger.subscribe(STRING, [](const StringMessage& msg) {
		std::cout << "Received: " << msg.message << std::endl;
	});
	messenger.send(StringMessage("Hello, messages!"));
	return 0;
}

Приведу также ссылку на статью с более общей реализацией обратного вызова (callback) ^[7] для нескольких аргументов.

Просадка производительности

Посмотрим насколько просели по производительности. Возьмём только по одному обработчику для двух мессенджеров, один из которых наш и может принимать любой унаследованный от Message тип. И второй, который умеет принимать только сообщение со строкой StringMessage. Будем посылать одно установленное сообщение много 500 000 000 раз.

Msg: 13955ms 
Str:  1176ms
Ratio:  12.0

В 12 раз медленнее. Вся разница уходит на взятие typeid типа аргумента при отправлении на одно сообщение и проверку на совпадение типов. Цифра удручающая, будем помнить о ней, но всё-таки не самая важная. Потому что скорее всего в программе возникнет узкое место не в процессе отправки сообщений, а в их обработке. И в самом крайнем случае можно убрать проверку на тип в релизном режиме, выровняв производительность.
Код замера ^[9]

Итоги

В итоге мы получили простую и вполне удобный прототип системы обмена сообщений. Весь код доступен на GitHub ^[10].

Автор: Parander

Источник ^[11]