Wataru

Очевидно, потому что возвращаемый тип имеет определенный оператор преобразования к int или long, но не имеет переопределенного operator+ с int.

Если смотреть описание возвращаемого типа, то там есть operator+ с каким-то streamoff, а с int - ничего нет. Там, правда, не указано, что есть опретор преобразования к int, так что это, наверно, тоже лучше не использовать.

Достоверно - никак.
Можно попробовать получить значение двух часов рядом и взять разницу между ними как сдвиг. Но тут будет какая-то минимальная ошибка из-за задержки между двумя вызовами. И, если пользователь поменяет часовой пояс в настройках системы, system_clock скакнет на несколько часов, поэтому надо по уму делать эту операцию каждый раз, когда вы хотите перевести одни часы в другие. И это дорого.

Вообще, если вам надо эти двое часов переводить в друг друга, то вы что-то не так делаете.

cout умеет сам по себе выводить только базовые типы: int, char, string, и т.д.

Ошибка об этом и говорит, что никто не реализовал оператор << для списка.

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

еще можно перегрузить оператор << для списка, тогда код в main останется без изменения, но тот же самый цикл придется все равно написать в операторе.

C++ - компилируемый язык. Соответственно, вы содержимое строки в нем никак не исполните, только если не напишите свой интерпретатор или не скомпилируете код в строке как-то подобно JIT. Можно подключить библиотеку с какой-нибудь Lua и код на Lua исполнять. Или подгружать в специально выделенную память скомпилированный заранее (или библиотекой) машинный код и передавать управление ему (но это надо знать ассемблер, про страницы памяти, API операционной системы и все такое. Это очень сложно). Вообще, C++ - не лучший выбор для динамической подгрузки кода.

defineCode(std::cout << 13 << std::endl); // work
Работает, потому что тут макрос просто подставляет код в скобках вместо себя и он компилируется и выполняется.

defineCode(stringLine); заменяется просто на stringLine, что есть бессмысленное выражение, вырезаемое еще на этапе компиляции.

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

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

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

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

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

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

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

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

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

А так вижу несколько ошибок. Обычно дерево отрезков реализуют только на массиве длинной в степень двойки. Добейте a нулями, до степени двойки. И тогда массив t может быть только в 2 раза больше a, а не в 4.

Далее, при реализации get надо, если отрезок вершины лежит внутри отрезка запроса, возвращать t[v]. в противном случае надо запускаться слева и справа, но тольо если запрос торчит в нужную сторону. Вы не запускаетесь от левого сына, если l > m, например. Можно считать значение 0, если рекурсивного вызова нет. В конце берете gcd двух половинок.

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