Можно ли узнать типы сигнатуры std::function?

Question

[Dyikot]

Например у меня есть шаблонный класс Event, который принимает THandler, обычно передаю std::function<...> с определнной сигнатурой (например void(Objeсt*, const EventArgs&>) т.е аргументов будет всегда два. Можно ли узнать вот эти типы: Objeсt и EventArgs?

Comments

[Дмитрий]

RTTI -- зло! С нормальной архитектурой он не нужен. Изучай различные паттерны, а не переноси JS в плюсы один в один.

[mayton2019]

А почему RTTI - зло?

[Евгений Шатунов]

mayton2019, потому что RTTI )))
Но это я просто вдогонку стиля беседы. В вопросе нет ни слова про RTTI, Дима на что-то свое подумал и вот так решил выразить свое мнение. Помогает ли его мнение хоть кому-то - вопрос отдельный. Особенно с учетом факта, что вопрос к RTTI даже косвенного отношения не имеет. Вопрос имеет крайне отдаленное отношение лишь к интроспекции, которая к RTTI тоже никакого отношения не имеет.

А вот дальше будет по сути дела.
Dyikot , вопрос у тебя понятный и даже обычный. Да, в общем случае можно узнать эти аргументы. Чтобы помочь тебе, сперва мне надо понять как ты хочешь распоряжаться полученной информацией. Допустим, у тебя уже есть знание об этих типах, пусть их будет даже не два, а заранее неизвестное N.
Что у тебя по ним в планах дальше? Как хочешь с ними работать?

[mayton2019]

Чтобы не запускать цепочку технических долгов. Евгений верно говорит что
желательно в фазе написания кода уже знать как мы будем дальше работать.
99% кодирования на С++ предполагают что мы всегда знаем типы и генерики
в фазе компилляции. Objeсt* - желательно выкинуть из кода и заменить его
каким-то базовым классом в известным интерфейсом. Тоесть принцип LSP
должен работать. Тоже со вторым аргументом.

В некоторых случаях (типичное Java/Spring приложение) информация о типах
в фазе компилляции нам неизвестна. Она приходит из runtime. Но на С++ это не типично
и лучше этого избегать.

[Dyikot]

Евгений Шатунов, Хотелось бы видить конкретные для данного события типы аргументов которые требуются передать. В данный момент я вызываю через шаблон.

template<typename TObject, typename TEventArgs> requires std::derived_from<TEventArgs, EventArgs>
void operator()(TObject* sender, const TEventArgs& e) const
{
	for(const THandler& handler : _handlers)
	{
		handler(sender, e);
	}
}

[Евгений Шатунов]

Dyikot, это оператор события?
Покажи как целиком выглядит событие. У тебя довольно рваная передача информации сейчас, мне приходится додумывать из своего опыта и пока я совсем не вижу никаких проблем и необходимости, благодаря своему опыту. Т.е. я считаю что тебе эти типы знать не нужно.
Тебе стоит точнее передать место твоей проблемы и как ты ожидаешь эту проблему решить через знание конкретных типов.

Если _handlers это коллекция делегатов, то они у тебя все одного типа и тебе про них все итак известно.

[Dyikot]

Евгений Шатунов, Вот -

Event

template<typename THandler>
class Event
{
protected:
	std::forward_list<THandler> _handlers;
public:
	void operator+=(auto&& handler) 
	{ 
		_handlers.emplace_front(std::forward<decltype(handler)>(handler));
	}

	void operator-=(auto&& handler) 
	{ 
		_handlers.remove(std::forward<decltype(handler)>(handler));
	}

	operator bool() const noexcept
	{ 
		return !_handlers.empty();
	}

	template<typename TObject, typename TEventArgs> requires std::derived_from<TEventArgs, EventArgs>
	void operator()(TObject* sender, const TEventArgs& e) const
	{
		for(const THandler& handler : _handlers)
		{
			handler(sender, e);
		}
	}

	void Clear() noexcept
	{ 
		_handlers.clear(); 
	}
};

Знать конечно не обязательно, можно всегда посмотреть, но хотелось бы если это возможно когда я начинаю писать оператор, и мне высвечивались конкретные типы для данного обработчика. Чтобы бы я не искал как там называется EventArgs для разных событий. Конечно это не критично. Но тут вопрос возможно ли узнать их.
UPD:
В общем разобрался как. Сделал отдельный класс:

template<typename TObject, typename TEventArgs> requires std::derived_from<TEventArgs, EventArgs>
class EventHandler: public std::function<void(TObject*, const TEventArgs&)>
{
public:
	using ObjectType = TObject;
	using ArgsType = TEventArgs;
};

и теперь в Event так:

void operator()(THandler::ObjectType* sender, const THandler::ArgsType& e) const
{
	for(const THandler& handler : _handlers)
	{
		handler(sender, e);
	}
}

[Евгений Шатунов]

Dyikot, если разобрался, то и хорошо.

Не будешь против моего личного мнения? :)

Код Event никуда не годится. Он неконтролируемый вообще.
Ты пишешь его как шаблон. В качестве аргумента инстанцирования передаешь тип хендлера, от которого внутри инстанцируешь тип поля - коллекцию хендлеров.
И вот именно с этого момента у тебя все должно быть под контролем и полностью известно, но нет. не в твоем коде.

void operator+=(auto&& handler)
Это называется обобщенной функцией. Тут у тебя оператор. Он обобщенный. Что это значит?
auto&& - это универсальное обобщение. Конкретный тип из него будет выведен в момент передачи аргумента.
Конкретный оператор у тебя из обобщенного будет выведен для типа каждого из переданных для его вызова хендлеров. Буквально в этот оператор ты можешь передавать все что только захочется и код будет пытаться собраться. Внутри оператора, в строчке

_handlers.emplace_front(std::forward<decltype(handler)>(handler));

код будет пытаться привести переданный тобой хендлер к типу THandler.
Насколько я вижу, ты используешь C++20 и тебе доступно неявное приведение стандартных функторов. В результате C++20 только усугубляет тебе проблему в коде, позволяя то, что ты написал.

Что у нас дальше.

template<typename TObject, typename TEventArgs> requires std::derived_from<TEventArgs, EventArgs>
void operator()(TObject* sender, const TEventArgs& e) const

Это шаблон оператора функционального вызова. Этот оператор из твоего события делает функциональный объект или функтор.
Но у тебя это шаблон. А инстанцируется он от любых аргументов, которые ты ему передаешь. И внутри кода шаблона у тебя код неявного приведения аргументов к типам параметров THandler.
И этот процесс ты вообще никак не контролируешь.

Этот код вообще никуда не годен. От него отказаться надо, наверное, прямо со вчера. Сегодня ты чуть-чуть переписал этот код, но по сути не сделал ничего полезного. И от этого кода все равно нужно отказаться.
Вот такое мнение вызвал твой код у человека, который ежедневно через code review проживает добрых 4 часа своей рабочей жизни.
Если спросишь про то, как тогда должно быть чтобы код был успешным, то я только предложу тебе изучить для начала как определяются и записываются типы функций и обратить пристальное внимание на то, как инстанцируются функторы из шаблона std::function. Постарайся разобраться с возможностями, которые тебе открывает мой совет.

[Dyikot]

Евгений Шатунов, Пытался улучшить как мог:

EventHandler

template<typename TObject, typename TEventArgs> 
	requires std::derived_from<TEventArgs, EventArgs>
class EventHandler: public std::function<void(TObject*, const TEventArgs&)>
{
public:
	using Base = std::function<void(TObject*, const TEventArgs&)>;
	using Object = TObject;
	using EventArgs = TEventArgs;
public:
	EventHandler() = default;

	template<typename TCallable> 
		requires !std::is_same_v<std::decay_t<TCallable>, EventHandler>
	EventHandler(TCallable&& handler):
		Base(std::forward<TCallable>(handler))
	{}

	EventHandler(const EventHandler& handler):
		Base(static_cast<const Base&>(handler))
	{}

	EventHandler(EventHandler&& handler) noexcept:
		Base(static_cast<Base&&>(handler))
	{}

	template<typename TCallable> 
		requires !std::is_same_v<std::decay_t<TCallable>, EventHandler>
	EventHandler& operator=(TCallable&& handler)
	{
		Base::operator=(std::forward<TCallable>(handler));
		return *this;
	}

	EventHandler& operator=(const EventHandler& handler)
	{
		Base::operator=(static_cast<const Base&>(handler));
		return *this;
	}

	EventHandler& operator=(EventHandler&& handler) noexcept
	{
		Base::operator=(static_cast<Base&&>(handler));
		return *this;
	}

	bool operator==(const EventHandler& eventHandler) const noexcept
	{
		return this->target_type() == eventHandler.target_type();
	}

	bool operator!=(const EventHandler& eventHandler) const noexcept
	{
		return !operator==(eventHandler);
	}
};

Event

template<typename TEventHandler, 
		 typename TObject = typename TEventHandler::Object,
		 typename TEventArgs = typename TEventHandler::EventArgs> requires
	std::is_base_of_v<EventHandler<typename TEventHandler::Object,
								   typename TEventHandler::EventArgs>, TEventHandler>
class Event
{
public:
	using EventHanlder = TEventHandler;
protected:
	std::forward_list<TEventHandler> _handlers;
public:
	void Clear() noexcept { _handlers.clear(); }

	template<typename TCallable> 
		requires !std::is_same_v<std::decay_t<TCallable>, TEventHandler>
	void operator+=(TCallable&& callable)
	{
		_handlers.emplace_front(std::forward<TCallable>(callable));
	}

	void operator+=(TEventHandler&& handler)
	{
		_handlers.push_front(std::move(handler));
	}

	void operator+=(const TEventHandler& handler)
	{
		_handlers.push_front(handler);
	}

	template<typename TCallable> 
		requires !std::is_same_v<std::decay_t<TCallable>, TEventHandler>
	void operator-=(TCallable&& callable)
	{
		_handlers.remove(std::forward<TCallable>(callable));
	}

	void operator-=(TEventHandler&& handler)
	{
		_handlers.remove(std::move(handler));
	}

	void operator-=(const TEventHandler& handler)
	{
		_handlers.remove(handler);
	}

	operator bool() const noexcept { return !_handlers.empty(); }

	void operator()(TObject* sender, const TEventArgs& e) const
	{
		for(const TEventHandler& handler : _handlers)
		{
			handler(sender, e);
		}
	}
};

Все же хочу оставить как шаблон. Если использовать не шаблон, то в качестве делегатов должны быть только нужные классы, т.е уже лямбы отпадают, мне такое не подходит. Сделал так чтобы в качестве аргумента для Event был только EventHandler.

[Евгений Шатунов]

Dyikot, но я ведь не ругался на саму шаблонность события. :)
Я ругался только на то, что у шаблона класса события есть шаблоны методов. Ты контроль потерял только из-за этого и сейчас из-за этого же пытаешься свой код подотунуть костылями.
Приведенный код никуда в плане качества не сдвинулся. Он такой же неудачный.

Наследоваться от стандартных типов - весьма порочная практика. Наследование - это вообще очень узкий инструмент. Оно подходит только тогда, когда ты можешь контролировать переходы объектов по иерархии наследования. У тебя же тут даже LSP у хендлера не соблюдается. Т.е. снова плохой код. Но позволь мне не вдаваться в объяснения, ведь тебе лучше все изучить и понять самому, почему я говорю именно так.

Подумай, каким образом из template< typename > можно получить и тип результата функции, и типы всех ее параметров всего за одну частичную специализацию шаблона.
Тебе не нужно передавать в событие тип хендлера.

[Dyikot]

Евгений Шатунов,

template<typename TObject, typename TEventArgs>
class Event<std::function<void(TObject*, const TEventArgs& e)>>

Так? Как-то не особо вникал в частичную специализацию. Всегда думал что у нее шаблон всегда пустой.

[Евгений Шатунов]

Dyikot, так. Но зачем тебе std::function здесь? Для чего ты обязываешь своего пользователя инстанцировать шаблон события именно таким образом?
Ведь это ни тебе(писателю шаблона), ни ему(пользователю шаблона) не нужно.

[Dyikot]

Евгений Шатунов, Ну а как хранить тогда callable объект? Я хочу чтобы событию я передал делегат т.е класс который хранит ссылку на callable объект. Можно конечно передать сигнатуру функции, но я хочу именно делегат. Можно конечно сделать еще одну специализацию.

[Евгений Шатунов]

Dyikot, требуй от пользователя только минимальную информацию для работы твоего кода.
Выводи недостающие для работы твоего кода части исходя из полученной от пользователя информации своими руками.
Тебя ведь ничто не останавливает от того, чтобы самостоятельно инстанцировать функтор из std::function из параметров шаблона события.

У тебя д.б. так:

template< typename >
class Event;

Частичная специализация защищает тебя от пользователя, которому захотелось странного.

template< typename TResult, typename... TArguments >
class Event<TResult ( TArguments... )> final
{
};

Дальше в этом коде у тебя все сразу под контролем. Выведи тип функтора, откажись от шаблонов операторов, используй выведенный тип функтора в операторах, используй параметры TResult и TArguments для определения оператора функционального вызова.
Шаблон простой как три копейки. Тебе незачем делать его сложнее. :)

[Dyikot]

Евгений Шатунов, Если что события я делаю чисто под себя, а не для библиотеки и поэтому оставлю std::function для удобства. В любом случае спасибо за уделенное время!

[Евгений Шатунов]

Dyikot, для информации.
Тут только прототип коллбека, т.е. тот же функтор. Все описано в репке. Не советую использовать этот код, я не задумывал его для использования в проектах.
Возможно код натолкнет тебя на какие-нибудь выводы. В моем коде все многократно серьезнее чем в этом прототипе, но событие и коллбек сделаны схожим с прототипом образом.
Ну и советую посмотреть на libsigc++ еще.

[Дмитрий]

mayton2019, потому что он нужен в языке, где всё можно выразить через систему типов, примерно в 1 случае из миллиона. Конечно же, exceptions -- тоже зло. 99% людей их используют там, где они вообще не нужны. Собственно, изначально RTTI в плюсах и появился исключительно чтобы поддерживать исключения.

Он даёт накладные расходы на диспетчеризацию в vtable, а это невозможность процессору предсказать переход, который ведёт за собой сброс кеш-линий, новый fetch инструкций на каждый чих, итого не сильно опытный разработчик может замедлить свой код в 3-4 раза; распухает бинарь от кучи мусора type_info, ломается и перестаёт толком работать LTO, даже замедлять начинает код.
Ну и, конечно же, архитектура. Узнавать в реалтайме тип объекта нужно примерно никогда, если код на С++ написан правильно программистом С++, а не JavaScript-кодером.

ПС. Я уже вижу, что дискуссия пошла в правильное русло -- в статическую типизацию и шаблоны.

Answer 1

[Юрий Борисов]

Универсальный вариант разобрать функтор на составляющие

#include <functional>
#include <string>

template <typename F>
struct HandlerTraits;

template <typename R, typename ...Args>
struct HandlerTraits<std::function<R(Args...)>>
{
    using ReturnType = R;
    using ArgTypes = std::tuple<Args...>;
    static constexpr std::size_t ArgCount = sizeof...(Args);
    template <std::size_t N>
    using NthArg = std::tuple_element_t<N, ArgTypes>;
};


template <typename T>
void processEvent(T const& handler)
{   
    using Traits = HandlerTraits<T>;

    static_assert(std::is_same_v<typename Traits::ReturnType, void>);
    static_assert(Traits::ArgCount == 2);
    static_assert(std::is_same_v<typename Traits::template NthArg<0>, std::string*>);
    static_assert(std::is_same_v<typename Traits::template NthArg<1>, int const&>);
}

int main()
{
    processEvent(std::function<void(std::string*, int const&)>{});
}

Answer 2

[Vindicar]

Обычно ты должен УЖЕ знать сигнатуру функции, чтобы принять ссылку на неё. Иначе как ты её вызовешь?

Comments

[Dyikot]

Через шаблон.

[maaGames]

Dyikot, Если тебе нужно знать тип, то у тебя ошибка архитектуры. Переписывай.
Если у тебя абстрактный интерфейс, то вся работа должна выполняться автоматически за счёт виртуальных функций. Всё остальное - костыли из-за ошибок архитекторы.