Wataru

Разность в поведении между сборками может быть обусловлена двумя причинами:
1) в коде есть ifdef и часть функциональности просто отключена в релизной сборке. Довольно часто так намеренно отключают отладочный вывод.
2) В коде есть ошибка, какое-то undefined behavior и при оптимизации в релизной сборке часть кода вырезается компилятором.

Какой-то другой причины чтобы cout не работал в релизной сборке я не вижу.

printf вы наверное сами куда-то добавили. Если заменить в коде библиотеки отсутствующий cout на printf оно так же работает? Или у вас нет доступа к коду?

Можно попробовать enable_if<> скомбинировать с is_base_of<>. Только нужно все ваши классы Id унаследовать от одного какого-то общего. И во всех наследниках объявлять int поле, которое и брать в теле функции. Только уже не получится этот int сделать параметром шаблона.

Надо линкеру указать dll-ку в которой эта функция определена. В документации не указано, в какой именно библиотеке оно лежит, но можно пропробовать Gdi32.dll или Ddraw.dll. Надо где-то в настройках проекта на вкладке про линкер указать эти dll.

Это еще ничего, а как вы хотите, чтобы парсилась строка "1111,2222,3333"? Как 11112222.3333? Или 111.22223333? Или что?

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

Например, можно просто читать сразу число. Если вам надо, чтобы число было корректным и при использовании '.' и ',', то можно просто все запятые поменять на точку.

Вам надо к вашему проету подключить библиотеки. Смотрите в свойствах линкера.

Смысл в том, что итак работает. Редко когда можно TLющееся решение переписать на другом языке программирования, и оно пройдет. Ибо все правильные решения различаются на десяки процентов, максимум, в разы. Неправильные же отсатют от правильных в десятки и сотни раз. По крайней мере на соревнованиях высокого уровня. А потом, ну просто лень составителям придумывать ограничения для всех языков программирования. А, поскольку оно итак работает, то никто этим не заморачивается. Многие системы тестирования даже не поддерживают разные ограничения под разные языки, и никто эту фичу не запиливает, потому что она никому и не нужна особо.

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

Что этот код должен, по вашему делать? Я отлично вижу, как он может в этих случаях вернуть false. Если ваш цикл в вашем UNORDERED мапе сначала возьмет самый последний символ сторки part1, то он присвоит переменной order максимально возможное значение и больше ни одино условие в цикле не выполнется - ни один символ больше не удалится.

Разница в поведении компиляторов обусловлена тем, что они по разному мешают этот самый НЕУПОРЯДОЧЕННЫЙ мап. Возможно, там разные хеш функции используются.

И, кстати, ваши multimap-ы тут вообще бесполезны. Во-первых, зачем вам MULTImap, ведь у вас все ключи - это индексы симовлов - уже разные. Во-вторых, зачем вам вообще map, если вы там по каждому индексу храние символ, что итак уже делает строка! У вас там part1map[i] == part1[i] всегда. Вместо цикла по мапу, можно пройтись циклом от 0 до длины строки.

Вы не ищите 2 максимума, а перебирайте все пары заборов, считайте площадь и выбирайте лучший вариант. Это точно будет работать, хоть и за квадрат.

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

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

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

Правильный ответ 8!. Ваше второе рассуждение упускает то, что вы одну и ту же позицию получите 8! раз. Ибо вы там считаете все фигуры уникальными. Допустим это все ладьи по диагонали. Вы первую можете поставить в 8 мест - одно из 64. Вторую в 7, когда выбираете из 49... И т.д. Вот и получится, что одну позицию - все на диагонали - вы подсчитали 8! раз.