Использование вариативного шаблона функции без аргументов?

Question

[Nexeon]

У меня есть объект класса Entity, который содержит список компонентов std::list<Component*> m_components

Сами компоненты представляют из себя классы, наследуемые от базового класса Component

С помощью функции bool HasComponent<T> я могу проверить наличие определенного компонента:

template<typename T> bool HasComponent<T> {
 T instance; //создаю экземпляр компонента

 for (auto component : m_components)  //for each 
 if (component->GetType() == instance.GetType()) { //если типы компонентов совпадают
 return true; //возвращаем true
}

//...

Entity mario;
if (mario.HasComponent<Velocity>) print("Mario can move!"); //пример использования

Но как мне одной функцией проверить наличие сразу нескольких компонентов?

bool HasComponents<Health, Velocity, Sprite>();

Я знаю что это можно реализовать с помощью вариативных шаблонов, но нахожу их применение лишь с аргументами, вроде этого: void foo(Args... args).

Вопрос: Как реализовать алгоритм для моего случая?

Answer 1

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

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

template< typename TComponentType >
bool HasComponent()
{
	return ...;
};

template< typename... TComponentTypes >
bool HasComponents()
{
	// Это тип предиката для проверки наличия одного компонента.
	using CheckingPred	= bool (*)();
	
	// Это тип листа проверки.
	using PredList		= std::array<CheckingPred, sizeof...( TComponentTypes )>;
	
	// Определяем лист проверки, следи за руками... :-)
	PredList predicates{{ HasComponent<TComponentTypes>... }};
	
	// Проверяем!
	return std::all_of( predicates.begin(), predicates.end(), []( CheckingPred stored_pred ) -> bool { return stored_pred(); } );
};

Сразу заостряю внимание на форматировании и стиле. Так сказать, что понятнее и удобнее читается? :)

UPD:
Еще предлагаю полистать библиотеку одного интересного товарища: https://github.com/alecthomas/entityx
Как я понимаю, тебе хочется попробовать реализовать ECS. EntityX - одна из самых прямых ECS библиотек на плюсах, если не сказать - самая прямая.

Comments

[MiiNiPaa]

HasComponent<ASingleType>() is ambiguous. Нужно либо отключать вариадик функцию, либо проводить реальную проверку в функции, названной по-другому.

[MiiNiPaa]

*Отключать для < 2 типов в списке.

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

MiiNiPaa , о_О??
Nexeon попросил вариативную `bool HasComponents()`, а не `bool HasComponent()`. :)

[MiiNiPaa]

Евгений Шатунов: Я не умею читать :). Не заметил эту s в конце.

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

MiiNiPaa , со всеми бывает. :)
Я на самом деле тоже не сразу ее увидел, у меня пальцы просто сами не смогли назвать вариативный шаблон `HasComponent`. ))

[Nexeon]

Cложно, постараюсь разобраться и подогнать под свой код.. затем отпишусь :)
Пока что вопросы вызывает сам предикат, нужно его более подробнее изучить..

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

Nexeon , я специально засунул лямбду в all_of, чтобы создать простор для модификаций.
На деле у тебя ведь `HasComponent` является member function? В этом случае тип предиката будет таким:
using CheckingPred = bool (Entity::*)();

В лямбде нужно замыкание на this от Entity, ну и вызов предикатов из листа будет немного другим:

auto my_entity = this;
return std::all_of(
	predicates.begin(), predicates.end(),
	[my_entity]( CheckingPred stored_pred ) -> bool
	{
		return (my_entity->*stored_pred)();
	}
);

[Nexeon]

Евгений Шатунов: К несчастью, не могу разобрать ваш код и идею, потому что просто не имею опыта. Вы пробовали тестировать его? Он работает? Задумываюсь оставить эту идею с подборкой нескольких компонентов методом шаблонов.

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

Nexeon , весь этот код уже можно отнести к разделу метапрограммирования в C++... Да, я все время забываю что это необычная тема.
Не прямо такой, а подобный код я имею обыкновение создавать и использовать в своей работе. Он работает. :)

Общая суть кода такова. Если мы можем проверить наличие одного компонента, то мы точно так же можем проверить и наличие множества компонентов сразу. Для этого нам надо знать функцию проверки каждого компонента из произвольного списка, после чего вызвать набор этих функций, аккумулируя результат.

std::all_of - простая замена цикла по итерируемому множеству с аккумулятором через операцию `&&`.
В качестве множества для std::all_of хорошо подходит массив указателей на функции проверки одного одиночного компонента.
В результате компилятор пишет код проверки группы компонентов за нас. :)

И еще вот наглядная демонстрация работы этого метода.
cpp.sh/8b5xo

Folding expressions безусловно удобнее... Все жду начала широкой поддержки 17го стандарта всеми популярными компиляторами...

[Nexeon]

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

[Nexeon]

Евгений Шатунов: Вдруг задумался над Вашим комментарием, то что сложность алгоритма равна M*N. Это крайне непрактично, если данная операция будет повторяться каждый кадр.

Думаю что лучше создать некую "чек-сумму" для каждой сущности, которая будет меняться при добавлении/удалении компонентов. Так будет проще и быстрее.

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

Nexeon , да, правильно. :)
Смотри, в EntityX, Autodesk Stingray, Artemis и у меня в моем фреймворке применяются маски и индексирование компонентов.

Коротко: на этапе компиляции (ага, снова метапрограммирование) для каждого типа компонента рассчитывается битовый индекс - это всего один поднятый бит на участке из N бит (int32_t, int64_t, 128, 256..). В EntityX, к примеру, это номер бита для std::bitset. Я предпочитаю снова все делать на этапе компиляции.
У каждой сущности есть битовое поле - маска компонентов. Когда компонент добавляется, в маске поднимается его бит, при удалении - снимается.
При этом, проверка наличия компонента делается через проверку соответствующего компоненту бита. А для проверки группы компонентов делается битовая маска группы, проверка все так же делается через одну операцию.

В Artemis и у меня есть возможность производить сложные проверки: найти сущность строго с такими компонентами (операция "и"), а еще с любым набором других компонентов (операция "или") и чтоб без третьих компонентов (операция "не").

Это уже потребует некоторой библиотеки метапрограммирования - MPL. Без нее сделать это все становится сложнее.

[Nexeon]

Евгений Шатунов: Про bitset слышал, но немного неудобно, на мой взгляд. Приходится следить какие биты уже заняты другими компонентами, плюс читаемость снижается (мне кажется)

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

Nexeon , поэтому всю работу по отслеживанию занятых битов и все обеспечение удобства работы перекладывают на компилятор. Ни один человек в здравом уме не начнет следить за обеспечением уникальности номеров битов для компонентов. :)

Чтобы уловить это все, тебе стоит почитать о том, как делался Autodesk Stingray.
bitsquid.blogspot.ru/2014/09/building-data-oriente...
Там 4 или 5 статей в блоге, далее по датам после вот этой.

Суть такова: компоненты для ECS сперва регистрируются. Это нужно не только для их индексации, но и для оптимизации хранения компонентов, и для оптимального управления компонентами для сущности.

Answer 2

[MiiNiPaa]

К примеру на С++17:

1) Переименовываете ваш текущий HasComponent в HasComponent_impl и делаете его приватным.

2) Создаёте новый HasComponent:

template<typename... Ts> bool HasComponent()
{
    return (HasComponent_impl<Ts>() && ...);
}

Пример.

Квадратичная сложность, конечно. Можно сделать лучше, но нужно ли?

Comments

[Nexeon]

К сожалению VS2015 не поддерживает функционал C++17, но способ хороший.

Answer 3

[Adamos]

Я бы в вашем случае погасил лампадку перед портретом Александреску и перестал насиловать компилятор.
Добиваясь поставленной цели, вы запутываете код - и при этом решительно ни в чем не выигрываете.