Dmitrii

Если числа такие большие, что ответ никуда не влезает, то надо писать длинную арифметику. Цифры числа храните в массиве, складывайте/умножайте в столбик. Удобно хранить числа развернутыми. Гуглите "длинная арифметика" - найдете и код с примерами и кучу статей.

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

Ваш код так ужасен, что я не могу понять, что вам там надо подсчитать в итоге, но уже брасается в глаза, что у вас там считается число сочетаний. Во-первых, можно считать (n-k+1*k+2*..*n)/k!, что уже дает более мелкие числа.

Потом, можно считать треугольником паскаля. Можно даже считать только одну строку, домножая и деля на одно число - тоже не получая в процессе чисел больше ответа.

Если bills не больше 64, то все влезет в стандартный unsigned long long.

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

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

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

Теоретически, ++i быстрее. Практически - нет, потому что компиляторы могут и то и другое соптимизировать в одни и те же ассемблерные инструкции в большинстве случаев. Исключение, если инкримент используется в выражении. Но тогда они не взаимозаменяемы. Еще может быть случай, если i какого-то странного типа и инкрименты перегружены и криво написаны. Или если оптимизация отключена при компиляции. Или у вас доисторический компилятор.

Можно работать с Arduino не как с Arduino, а как с тем чипом, который в ней стоит - тогда можно будет использовать любой язык, который может запускаться на целевой архитектуре (AVR, arm, итд).
Среды разработки будут соответствующие.
Если используется си, то подключение сишных библиотек будет вполне очевидным.
Иначе используется ffi специфичный для конкретного языка. (например в случае rust можно использовать bindgen)

Также для Arduino есть среда разработки Platformio - там используется также язык arduino, который C++, но писать будешь не в убогом стандартном редакторе, а в vscode

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

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

Чтобы устроитсья, тебе нужно уметь работать, а не пет проект, не заморачивайся.

Читай то что вводит пользователь как строку, а потом std::from_chars

Практически никак. Суть полиморфизма в том, что экземпляры наследников можно вставлять вместо экземпляра предка везде и все будет работать. Поэтому вы средствами языка никак не запретите передавать C вместо B (речь об указателях, естественно). Если хочется, то можно сделать виртуальную функцию, которая возвращала бы какое-то enum, для идентификации классов A,B,C (и других наследников) и уже в функции проверять, что там не передали по ошибке экземпляр C. Но логичнее было бы выделить каие-то свойства у классов (например, количество пуль в вашем примере с MultiGun) их задать в виртуальных функциях у всех классов и дальше в функции проверять, что переданный экземпляр обладает нужными свойствами. Жестко привязываться, что можно B, но нельзя C - это плохой подход. Почему нельзя? А если потом появится D,E,F - можно ли их передавать? А если они братья B?

У тебя ошибка в логике.
Ты проверяешь каждую возможную гласную, и если слово начинается с неё, ты выводишь "an".
Но если слово НЕ начинается с этой гласной, ты выводишь "a", что ошибочно.
Ведь тот факт, что слово не начинается с этой гласной, ещё не означает, что оно не начинается вообще с никакой гласной.
Поэтому раздели две операции - проверка гласной, и вывод.
Ну или научись пользоваться оператором in, как выше подсказал Dmitrii.

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

P.S. такую штуку действительно иногда используют, но ради того чтоб вызвать деструктор в нужной точке кода.

Запакуй своё приложение в пакет для конкретной операционной системы и всё.
В случае линукса - зависит от конкретного дистрибутива, там куча разных пакетных менеджеров.
На винде - msi или msix

Ну и не всегда есть смысл вообще делать инсталляторы - консольными приложениями на Windows пользуются "продвинутые" пользователи и у них явно не будет сложности с тем, чтобы прописать его в PATH.

Для первого - и в винде, и в линуксе для этого достаточно прописать путь к папке с исполняемым файлом в PATH - все терминалы (наверное все) именно там ищут "команды" (а точнее команда это и есть бинарь).