floppa322, Действительно, упорото. Но в этой задаче используется тот факт, что числа небольшие. Поэтому часть вершины соответствуют всем возможным значениям силы каждого волшебника. Кроме того там на каждая переменная "переворачиваем ли конкретную пару" участвует ровно в двух неравенствах. Вот это число 2 и позволяет как-то не ребра это натягивать.
Что-то подобное в задаче про самолет не придумать, тут или мы или берем человека или не берем. И это в контексте потока отлично ложится именно на велечину потока или ребро в разрезе. А дальше опять вылезают сложные условия - каждая переменная втречается в куче неравенств по всем промежуточным перелетам.
floppa322, Мне здается, что автор задания не заметил эту проблему. Если можете, спросите у преподавателя, а не подразумевается ли вот такое решение в качестве эталонного:
Граф из n вершин + s и t. Ребро из i в i+1 пропускной способностью k, ценой 0. Ребра из s в i пропускными способностсями pij ценами -fij. ребра из i в t пропускными способносями pji ценой 0.
Подразумевается, что любое назначение каких пассажиров берем соответсвует потоку из s ->i ->i+1... -> j -> t. Ограничения на ребрах i->i+1 задают вместимость самолета.
Вот только проблема в том, что какой-то поток в этом графе может не соответствовать решению, ведь может так получиться, что пассажир выйдет не на своей вершине.
Вот эта первая проблема - она принципиальная и никак в потоках не решается. У вас все пассажиры не взаимозаменяемы в задаче. Но в потоке все единицы "жидкости" идентичны. При попытке потоком ограничить количество пассажиров в самолете вы их всех смешиваете в одном ребре. А дальше они уже все неразличимы и заставить одних идти туда, а других сюда - никак нельзя. Поэтому если и сводить к потоку, то у вас не может быть ребра пропускной способности k и ограничения должны как-то подругому применяться.
Вы уверены, что задачу можно свести к потокам? Она у вас в теме на потоки дана? Или вы просто подумали, что тут можно потоки применить? Какие ограничения в задаче (насколько большие числа n, k)?
blecked88, Ваш фикс действительно сделал CRC этого кода неизменным. Но также сделал высчитывание CRC бесполезным. Теперь у хакера есть очень удобная отдельная функция _strcmp, которая выполняет важные вам проверки. Ее очень просто пропатчить.
jcmvbkbc, Я был не совсем прав. Я прав в том, что в приведенном коде изменяются какие-то адреса связанные с вызовами функций. Но вы правы в том, что там не используются абсолютные адреса в call. Это потому что там используется Import Address Table при вызове, а она лежит в перемещаемой секции данных.
blecked88, можно на ассемблере вручную написать код, который никих функций не вызывает. И все jmp внутри должны быть с относительными адресами. Вот только это все бесполезно по большому счеты. Если вы подозреваете, что исполняемый файл будут изменять, чтобы обойти проверку, то ничего не стоит злодеям и все ваши проверки точно также вырезать.
bamandr, Потому что автор в вопросе говорит "хочу считать их в массив". Multiset - это более продвинутая структура данных, которая в данном случае будет сильно медленнее вектора. Она нужна для алгоритмов, которые часто проверяют, есть ли искомый элемент среди данных или нет.
Но вообще, эта задача рашается без векторов. Я так полагаю, входные файлы отсортированы и надо выполнить операцию слияния. Тут надо в цикле читать из обоих файлов, пока один из них не закончится. Записывать в ответ минимальное число и читать следующее в файле, из которого меньшее число пришло.
Test-username-1642, Очень голословное утверждение. Вы уверены? Это джаваскрипт. Там память выделяется на каждый чих. Вы можете гарантировать что выполнение xor не выделит новую переменную? Если же там происходит jit компиляция, или мы говорим про какой-нибудь другой язык более бережливый к памяти, то тут тоже нет приемущества по памяти, потому что есть такая вещь, как регистры процессора. Поэтому никакого потребления памяти для переменной tmp не будет в 99.99999% случаев.
Test-username-1642, Можно, конечно, но зачем? Операций будет все так же 3 штуки, однако код станет менее понятен. С учетом, что автор запутался в циклах в таком простом алгоритме - это точно не то, что стоит делать.
Евгений, Ну допустим это цены не в рублях, а в копейках. Вам надо 7 копеек раскидать по позициям в которых amount 5 и 3. Это без разбиения позиций невозможно вообще. Вам можно разбивать позиции? Можно получать скидку прмерно целевую +- несколько копеек?
