xmoonlight, ну да, это все усложняет возможность подтасовки.
Однако сложность алгоритма уже такова, что человек, способный его понять... скажем, достаточно умен, чтобы не играть в азартные игры ;)
xmoonlight, еще раз: именно это и создает обратную связь. Устроителю невыгодно внедрять подсадку, потому что все будут думать, что это подсадка, и никто не будет участвовать. В среде, где люди не совсем незнакомы (например, в онлайн-игрушке или соцсети) - такая схема вполне может сработать.
А в среде полных анонимов делать ставки - ну, это же несерьезно, какие бы там ни были математические сервисы...
xmoonlight, именно в предположении, что человек, сделавший максимальную ставку, на виду.
Если это постоянно будет кто-то левый - репутация разыгрывающего скроется под плинтусом.
xmoonlight, разве что организационно.
Например, после того, как все ставки сделаны, предоставить участнику, выкупившему максимальную долю, выбрать случайное число с тем, чтобы оно тоже участвовало в расчете.
xmoonlight, с т.з. участника всего этого цирка - тот сервис должен иметь немалую репутацию действительно независимой третьей стороны. Иначе вполне закономерно предположить сговор между ним и устроителем, а то и прямую связь, закамуфлированную от участников таким образом.
Первый вариант предпочтительнее еще и тем, что поддержкой этого хозяйства будет заниматься сторонний сервис. А не человек, который вместо гугления задает вопрос на Тостере ;)
xmoonlight, бритва Оккама быстро сводит воедино держателя сервиса и устроителя.
Но даже если они реально независимы - как устроитель, в свою очередь, может верить сервису, у которого в руках все козыри? Приходим туда же.
xmoonlight, сервис сервисом, а что помешает директору цирка перед самым финалом вбросить от имени Васи Пупкина решающие полтора голоса, которые сменят победителя в этом алгоритме на более нужного?
Проблема в том, что, имея алгоритм, владелец может подтасовать победу, вводя выдуманных участников с нужными долями. Не будет же он у каждого требовать паспортных данных и публиковать эту информацию.
Если при добавлении новых записей обновлять отдельную табличку с конкретно этими данными и запрашивать только ее - все будет работать из кэша в памяти, это быстро и ненапряжно.
Но, имхо, сам вопрос - первый звоночек насчет архитектурных проблем...
tr1ck1, во-первых, это новое ядро безобразно документировано.
Во-вторых, оно в первую очередь призвано подпереть старую архитектуру.
В-третьих, народ на форумах разводит руками: обновление кода на D7 внезапно делает его на порядок(!) медленнее - запросы к базе оказываются еще менее оптимальными, чем были в старом ядре...
Евгений Шатунов, ну, не пересказывать же учебники.
Смотрите, вы же можете передать в функцию func(std::string) строковый литерал?
И вам не приходится вручную загонять его в конструктор std::string?
Для решения проблемы достаточно создать класс StringOrFloat с двумя конструкторами, принимающими, соответственно, String или float.
И в функции задать оба аргумента - именно этого класса.
У вас же, судя по применению шаблона, все равно к чему-то единому приводится значение аргументов.
Однако сложность алгоритма уже такова, что человек, способный его понять... скажем, достаточно умен, чтобы не играть в азартные игры ;)