Вызов функции из аргумента(C++)

абстрактивно он бесплатен

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

передачи интов by const-ref?

а при чем тут енто?

std::function стирает часть информации о типе.

где ты такое вычитал в стандарте языка с++? Если это догадка по определенной реализации компилятора — то это лишь определенная реализация. Компилятор может и с указателями на функции делать что угодно тогда уж — многие проверки накладывать...

Мне лень лезть в стандарт, но по-моему это очевидный факт. Если в одну и ту же переменную можно положить 1) указатель на функцию; 2) указатель на метод; 3) произвольный объект-функтор - то часть типовой информации тут безвозвратно потеряна.

std::function стирает часть информации о типе.

где ты такое вычитал в стандарте языка с++?

Не поверите - это его (std::function) единственное предназначение. Мне очень жаль что Вы этого [пока ещё] не поняли.

«The closure type for a lambda-expression has a public inline function call operator (for a non-generic lambda) or function call operator template (for a generic lambda)» — стандарт говорит, что инлайновый оператор скобок. При этом он может быть как constexpr, так и consteval — «The function call operator or any given operator template specialization is a constexpr function if either the corresponding lambda-expression’s parameter-declaration-clause is followed by constexpr or consteval, or it satisfies the requirements for a constexpr function (9.1.5). It is an immediate function (9.1.5) if the corresponding lambda-expression’s parameter-declaration-clause is followed by consteval.»
Пример с лямбдой на борту — лямбда так же отрабатывает как и обычная функция — и ее «конструирование» сводится к выставлению смещения. — Это без оптимизаций — с ними и это просто выкидывается.

так сама std::function хранит сведения про переданный ей функциональный объект — не важно что это было — а программисту в принципе знать этого не важно почти никогда.

так деды как раз понимают — по данной причине и сделали std::function... (как и многие другие удобства и оптимизации)
[P.S.](может еще и vtable делать ручками?)

if(AvailableCommands.find(command) != AvailableCommands.end()) { return true; }
return false;

можно заменить на просто

return AvailableCommands.find(command) != AvailableCommands.end()

else if (command == «exit»)

а вот тут у тебя не выполнится никогда — поскольку в предыдущем блоке if будет выполнено.

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

а кто не надеется на компилятор?

commandIsCorrect(const string &com){

тогда уж принимать как он принимает и делать std::move(com) в map.find()...

а то в твоем случае когда будет r-value создастся строка и будет копирование.

тогда уж std::string_view — но тут уж что надо — владеть или не владеть...

заменять токенами/литералами/объектами

так строки тоже могут быть литералами — с c++20 у них constexpr конструктор

тогда уж принимать как он принимает и делать std::move(com) в map.find()…

а то в твоем случае когда будет r-value создастся строка и будет копирование.

у него функция просто ищет в map наличие некоей строки. зачем ее куда-то копировать или двигать??? map::find берет агрументом констатную ссылку. зачем для map::find делать еще и move? просто надо передать константную ссылку с самого начала и все.

у него функция просто ищет в map наличие некоей строки. зачем ее куда-то копировать или двигать???

ну когда передастся r-value в функцию — будет лишнее копирование если сделать const& string

ну и да — std::move ничего не делает вообще, кроме как форсит мув-семантику

так деды

Пожалуйста, даже не пытайтесь - к этой группе людей вы однозначно не относитесь, как бы вам не хотелось.

как раз понимают — по данной причине и сделали std::function… (как и многие другие удобства и оптимизации)

Вот никакого отношения к оптимизациям std::function не имеет.

передачи интов by const-ref?

а при чем тут енто

Не удержался. При многом. Потому как собираемся пушать 64 бита там где 32-ух должно было хватить. И лишний indirection. Но куда уж дедам-то, они же вообще попИсать вышли…

дак я ж про то, что с чего вообще такая мысль возникла? вроде же никто тут ничего такого не спрашивал и не говорил...

к этой группе людей вы однозначно не относитесь, как бы вам не хотелось.

конечно нет — как и ты...

а по поводу таргетно о с++ — тут вообще все очень строго с принятием новых фич, очень сложная система приобщения чего либо к стандарту — посему прям могу утверждать, что любое нововведение в стандарте с++ это именно необходимые улучшения, без которых были очень сильные неудобства или просадки производительности, а так же баги связанные с безопасностью и подобным.

что с чего вообще такая мысль возникла?

Господин fsb4000 решил ускорить вызов by function pointer. Там всё интересно конечно… И ему (возможно) до сих пор не очевидно в чём про%^. Не смотря на то что он довольно «крут»…

Даже если оно где-то станет void*, то опираться на это - такое себе.

про опору тут я не говорил — просто абстракция с++ не указывает что из себя представляет указатель на функцию, — говорится лишь, что это отдельный тип указателя. По сему нельзя утверждать и обратное, что такой указатель не является void* — мой посыл был про это именно. Как реализовано в отдельно взятом компиляторе — не является чем то значимым.