в выводу, что лучше использовать ссылку на функцию (как вариант - function_ref, или https://github.com/zhihaoy/nontype_functional )
Вот смотрите, есть класс кухня и внутри кухня держит экземпляр абстрактного кипятильника.
Ты можешь в любой момент подсунуть туда любой механизм, что умеет кипятить
(при условии что он унаследован он абстрактного кипятильника).
Также ты можешь держать std:: variant чайников и подсовывать любой чайник (бойлер, электро, или самовар ).
(и тогда нужен визитор).
Третий вариант это type_erasure - данный подход хорошо описан тут - https://www.foonathan.net/2020/01/type-erasure/
А вот смотрите как можно гораздо проще с функциями, вместо классов-рабочих.
Ты держишь просто в качестве члена данных указатель на функцию , функция принимает сырую воду и отдает кипяток.
В этот указатель на функцию просто кладешь любую функцию, что принимает воду и отдает кипяток.
Ты можешь сделать шаблонную функцию, создать её с параметром типа Самовар.
И ты передашь в нее сырую воду.
Что происходит внутри этой функции, твой класс, как пользователя кипятильника, не интересует.
Внутри же просто создаётся самовар , мы пользуемся им и потом наружу отдается кипяток из функции.
Тебе не надо все время держать на кухне кучу самоваров и чайников. Ты просто держишь книгу рецептов.
Если тебе надо что то получить, ты тупо исполняешь рецепт (а в рецепте уже написано возьми самовар, ,налей в него воду и т. д.)
И не надо также городить никакие виртуальные функции и визиторы.
Я пришел к выводу, что объекты они конечно нужны сами по себе,
но они лишь служат временно для достижения цели.
Тебе не надо допустим, в твоём классе огород все время держать кучу тракторов и культиваторов.
Они будут тупо занимать пространство (память). Ты трактором пользуешься раз в год.
Проще держать указатель на функцию,
а в него уже класть функцию "пашня вспаши<трактором>(земля)" или пашня вспаши<негром_с_лопатой>(земля)
Если функция одна - ок. Если функции две или есть ещё данные рядом, уже менее удобно стирать тип, поэтому используют классы
А чем плох вариант держать умный указатель на интерфейсный класс?
Так тоже можно, да. Подсовываешь в указатель на базовый класс фактический класс-трудягу.
А статический полиморфизм делает инлайнинг и избавляет от накладных расходов в виде vtable и косвенных вызовов функций по их указателю.
Обсуждают сегодня