Adamos, Она вам задана рекурсивно. Если там не написано, что надо ее именно так написать в коде, то - нет.
Если в задаче, например, сказано, что F(x) = sum i=1..x i, то функция заданна циклом. Но ее можно реализовать как x(x+1)/2.
Если вам надо обязательно иметь в коде рекурсивную F, то никак особо вы код не с оптимизируете. S разверните в цикл - и все. Но этого, скорее всего, не хватит.
ASASDASDASDA, Только не забывайте, что это лишь указатель на память, которой владеет string. Поэтому если у вас str в примере выше выйдет из области жизни и удалится, то str_ptr останется висячим указателем.
В какую-нибудь функцию системную, которой char* нужен (и он там не сохраняется после, допустим, вывода), на вот возвращать из функции и в глобальные переменные пихать - очень опасно.
Смотрите: вы добавляете в граф какие-то ребра. Надо чтобы после этого кратчайшие пути между заданными парами вершин укладывались в заданные ограничения. Ведь добавляя ребра вы можете какие-то пути улучшить (какие-то может и не улучшатся от каких-то ребер, но хуже нигде не станет. Ведь никто не заставляет пакеты ходить по новым ребрам).
Среди всех вариантов добавить ребра и уложиться в ограничения вам надо выбрать тот, который использует наименнее дорогие добавления. Не суммарно, а худшее.
Sunter, Ну, время - путь в графе кратчайшей длины. В примере 2 добавив "1 3 1 3" вы создали путь из 1 в 3 длинной 3 (из одного нового ребра). Он укладывается в нужное ограничение.
Добавление ребра "2 3 2 1" не помагает, потому что оно участвует в пути 1-2-3, и его стоимость 2+2 = 4, не укладывается в лимит по времени. Но добавить его в ответ все-равно можно, потому что цена добавления 1 меньше цены первого добавления. И кратчайший путь в графе (где длины ребер - время) все еще остается 3, через одно новое ребро 1-3.
Sunter, простите, ответил на коммент до редактирования. Там на самом деле неважно и только второе предложение и оба вместе дают одинаково хороший ответ, ведь второе предложение самое дорогое. Так что 1 2 тоже валидный ответ.
Danilka2400, Ну, если числа такие маленькие, то нафига вам их в hex хранить в массиве? Массивы смело урезайте до 1-2 элементов и вообще заменяйте на word.
Вот только весь этот подход не будет работать, если у вас в ваших числах не так много ведущих нулей. Что-то вроде {0x40, 0x42, 0x0F, 0x00, 0x00, 0xFF} * {0x04, 0x02, 0x00, 0x00, 0xFF} переполнится. Каждый из x и y еще вы подсчитаете, а их перемножение уже в word не влезет. Да и даже в 64-битный тип (Ибо там 66 бит наскребется суммарно).
Rsa97, Ну нет, если дерево ленивое, а не как куча в массиве фиксированного размера, то там будет менее чем в 1.5 раза больше вершин, чем элементов сохранено. И менее чем в 1.5 раза больше, чем единичных ячеек.
Rsa97, Ну... если хранить разряженный map из координат квадрата в список игроков там, то это будет работать да. Иначе потребление памяти будет астрономическое.
Ярослав Иванов, Ну тогда никакого транзитивного замыкания не надо. Просто для каждого игрока в окто-дереве ищите соседей, запоминаете, что он с ними общается.
А если они в линию выстроены. Первый пересекается со вторым, второй с первым и третьим, третий со вторым и четвертым и т.д. Тут они каждый с соседями общаются, или все со всеми?
Если первый вариант, то все как я описал. если второй, то серверу после построения соседий придется еще каким-нибудь посиком в ширину или в глубину найти компоненты связности (или транзитивно замкнуть граф соседей).
> У игрока нет возможности спрашивать. Это сервер решает кому и что отправлять
Ну, будет как я написал в начале абзаца. Сервер решает переодически кто кому сосед и потом что хочет с этим делает.
#, Да не, разделение-то нормальное. Имена плохие. Назвали бы их term1 и term2. И вообще первый надо разделить на numerator и denominator, в котором у вас и была ошибка.
Если в задаче, например, сказано, что F(x) = sum i=1..x i, то функция заданна циклом. Но ее можно реализовать как x(x+1)/2.
Если вам надо обязательно иметь в коде рекурсивную F, то никак особо вы код не с оптимизируете. S разверните в цикл - и все. Но этого, скорее всего, не хватит.