если можно избавившись от класса просто тоже самое написать в методе?
А, что даёт *(float*)?
void*, а чтобы начать с ним работать, его нужно привести, минимум, к адресу на переменную конкретного типа.(float*) из void* сделает float*, а звезда слева - это разыменование указателя, в результате которого получается float&. После этой легкой операции с памятью по адресу можно работать как с переменной типа float.И как в данном случае должна выглядеть разметка?
И вот r-value на этот самый type и используется для инстанцирования вызовов с переданным к-value значением, а версия с l-value ссылкой на этот type используется для инстанцирования с l-value значением.
std::remove_reference применяется только к параметру std::forward и нужен для реализации одного конкретного случая. Тип результата у std::forward все так же выводится с помощью reference collapse rule.Только целые, никаких user type.
constexpr не больно-то больше свободы. constexpr является рекомендацией, а не указанием. Рекомендация накладывает ограничения на код, но ничего не запрещает компилятору.constexpr в рантайме. static constexpr const.
Описание в "назначении" шаблона фабрики на этом сайте не описывает ничего. Особенно фабрику.
Более того, примеры бестолковые. Они поясняют только то, как не надо использовать порождающие шаблоны. Вот как там в примерах показано, так и не надо делать.
Можно всю программу зафигачить в одной функции и при этом единственная функция будет выполнять все требующееся от программы. Зачем нам вообще эти шаблоны дались?
В тот момент, когда тебе потребуется расширить функциональность уже долгое время стабильно работающего кода (~2MB текста), с каким кодом тебе будет удобнее работать? С кодом, в котором все свалено в одну большую кучу и который надо переписывать целиком при каждой доработке? Или с кодом, в котором есть элементы абстракции, работающие как точки возможного расширения функционала, и где для расширения функциональности достаточно просто внедрить новые элементы конкретики для абстракции?
Касательно самой фабрики и фабричных методов нужно сразу уяснить себе два важных момента.
Момент первый. Фабричный метод производит объекты только одного конкретного типа в безусловном режиме. Фабричный метод нужен как абстракция над процессом создания объекта.
Все фабричные методы для одного семейства классов всегда имеют единую сигнатуру и всегда могут использоваться без знания конкретных классов семейства.
Часто, почти всегда, конкретный фабричный метод семейства выполняется как статическая функция конкретного класса этого семейства.
Ключевым моментом фабричного метода является то, что для любого семейства классов, для которых созданы фабричные методы, имея на руках набор аргументов и абстрактный фабричный метод, вызвав метод с передачей аргументов ты получишь объект с общим интерфейсом этого семейства.
Момент второй. Абстрактная фабрика - это просто агрегатор фабричных методов. Абстрактная фабрика связывает конкретный фабричный метод с неким состоянием конструкции, которое часто выражается в виде еще одного параметра.
Абстрактная фабрика - это буквально ассоциативный массив из
состояние => фабричный метод. Само собой понятно что это объект некоторого класса, а не сам класс. Это важно понимать.Т.к. сигнатуры всех фабричных методов в рамках одного семейства одинаковы, абстрактная фабрика легко складывает их в ассоциацию. Саму же ассоциацию устанавливает только сам программист, регистрируя фабричные методы в фабрике и ассоциируя их с неким состоянием.
И вот где здесь точка абстракции.
Пользователь фабрики никак не обременен знанием конкретики семейства, экземпляры классов которого создает фабрика. Тип фабрики реализован так, что его, по факту, можно использовать и для другого семейства со схожими условиями конструкции. Прикладные типы семейства предельно конкретны и реализуют строго свои функции, не распыляясь на код менеджмента того или иного шаблона.
И самое главное - благодаря регистрации методов в фабрике, ее расширяемость перестает зависеть от ее кода. Регистрировать новые классы можно и в других подсистемах, в других слоях, далеко за пределами текущей подсистемы и текущего слоя архитектуры.