Как раз нормальную. На время праздников. Сначала отпразднуешь, потом делать будет нечего, вот и займешься от того самого «нечего делать». Глядишь, и приз выиграешь. На это, мне кажется, и был расчет.
А при чем тут потоки? Это реализация задумки — что-то сделать с данными из файла. Если сначала десериализовать, то этих ограничений нет. Хотя там тоже есть потоки. Парадокс, не так ли?
Т.е. я хочу сказать, что у предложенного метода есть ограничения, связанные с приведенной реализацией. При другой реализации их нет.
А если надо отсортировать числа, то что тогда? Этот способ работает только в очень ограниченных случаях:
1. Возможно использование только Forward Iterators. Другие, такие как Reverse Iterator, Bidirectional, Random нельзя.
2. Контейнер содержит только old-plain data. Это тоже очень сильное ограничение, никакие классы, ООП и проч. нельзя использовать.
3. При всей кажущейся оптимальности, данный способ будет проходить по всем элементам, невзирая на то, что можно остановиться на первом элементе. Если же сделать реализацию, чтобы он останавливался, то тогда возникает следующая сложность: а что, если у нас контейнер содержит несколько контейнеров? Что тогда? Как перейти от первого ко второму?
Да, для частного использования частного вида задач это и можно использовать. Но для общего случая этот способ не очень подходит. Поэтому хотелось бы видеть не только идею, но и анализ: когда можно использовать, когда нельзя, какие ограничения. А также в чем выигрыш по сравнению с десериализацией и проверкой в контенере.
Как раз так делать нельзя. Почему-то под object всегда понимается old-plain structure. А если это класс, который содержит всякие вектора и мапы? А если в функцию передали ссылку на производный класс, а сама ссылка является ссылкой на базовый? Это прокатывает только в простейшем случае, который в большинстве случаев неинтересен.
Основная идея — сначала сериализуем в контейнер, а затем проверяем. Можно, конечно, заявить, что это не совсем то. Но на самом деле как правило нужна именно сериализация, т.к. операции в памяти делаются гораздо быстрее, чем в файле. Предположим, что надо отсортировать данные файла, которые представляют собой int. Мне сложно представить, как это делается указанным выше способом. В boost:serialization это делается просто.
Забавный пост. Все, что написано — это велосипед, причем пронафталиненный велосипед. Посмотрите в сторону boost::serialization, и вы поймете, что это уже давно сделано на более профессиональном уровне с учетом различных контейнеров, shared_ptr, полиморфизма и поддержкой версионности.
Дело в том, что само по себе юнит тестирование не говорит о том, какой unit можно брать для тестирования. Часто под этим понимают класс, но это может быть как отдельная функция, так и целый модуль. Если требуется производительность, то стоит подумать о том, чтобы тестировать модули как целое. Тут главное, применять эти принципы без фанатизма, а так, чтобы было действительно удобно и способствовало тестированию и выявлению ошибок на ранних стадиях. В нашем проекте большинство юнит тестов написано именно на модули, а не на отдельные мелкие сущности. И могу сказать, что производительность была на первом месте, и она не пострадала. Дополнительные методы — да, но они никоим образом не нарушали инкапсуляцию.
Мне кажется, если язык не предназначен для простой реализации простых идей, то стоит задуматься, а надо ли это вообще? Может выбрать другой инструмент? Можно для шурупа использовать молоток, но может лучше взять отвертку? А вообще статья интересная. По крайней мере понятно, что в продакшене лучше сюда не ходить :)
В том-то все и дело, что сущность простая, а реализация совсем очень даже не. Хороший язык — тот, который позволяет простые идеи реализовывать просто. Это не про С++.
Я посмотрел ваши игры. Мне кажется, если улучшить алгоритм атаки и более активно атаковать муравейники, то вы можете значительно сильнее продвинуться. Мой текущий алгоритм не может защищать муравейник, зато более агресивно атакует чужой и старается атаковать муравьев с выигрышем (по крайней мере без проигрыша). Это позволяет выступать успешнее, хотя часто я проигрываю муравейник.
А можно поинтересоваться, под каким ником вы зарегистрированы в AI Challenge? Это для того, чтобы посмотреть игры, которые используют приведенный алгоритм. Очень интересно.
Можно сохранять любую промежуточную информацию в любом месте (памяти своего процесса). Но прикол в том, что это не сильно помогает. Мой бот на 20-й позиции и я могу перечислить недостатки:
1. Нет нормальной защиты муравейника. Она есть, но должна быть гораздо более сильной. На это надо тратить немало времени, чтобы сделать достойную защиту.
2. Нет нормальной атаки чужих муравейников. Опять же, она есть, но надо это делать гораздо более целеустремленно. Этот фактор имеет крайне важное значение в самом начале игры, когда противник слаб и можно быстренько его захватить.
3. Атака/защита должна максимально следовать правилам чтобы правильно расчитывать шансы. У меня алгоритм использует свой анализ и иногда сливает.
4. Сбор еды должен идти постоянно. Чем больше котролируемая территория, тем лучше. Т.е. муравьи должны увеличивать видимую часть территории. Это тоже очень важно. При правильном развитии можно других легко задавить числом.
Мне кажется, что если этого не было и вы хотите попробовать, то это не повод делать так, как вам удобно. Т.е. это можно сделать так, но при этом вызовет массу вопросов и нареканий. Потом вы конечно можете сказать, что дескать мы попробовали и не получилось, но зачем ставить заранее условия, которые явно хуже того, что было у других компаний, хоть и не российских. Т.е. отговорка, что мы хотим попробовать — она очень слабая. И это действительно отговорка, потому что есть положительные опыты других компаний, которые делали совершенно по-другому. Вам намекают на то, что это не очень справедливо, а по большому счету убивает изначально желание начинать работать в этом направлении. Это работа, и работа непростая. И если вы привлекаете людей на эту работу, то она должна быть оплачена. Почему? Да потому что у вас в штате есть люди, которые этим занимаются и которые получают за это вполне реальные деньги. Такая постановка задачи как бы намекает на ряд моментов. Например: мы не знаем, сколько у нас уязвимостей, возможно, что их много; поэтому мы решили тут немножко сэкономить, во-первых, чтобы не набирать себе высокооплачиваемых людей по безопасности, а во-вторых, чтобы не разориться на выплачивании за каждую уязвимость; вот когда мы узнаем какое их количество, вот тогда поделим одно число на другое и тогда будет другой разговор. Другой причины я не вижу. Извините.
Т.е. я хочу сказать, что у предложенного метода есть ограничения, связанные с приведенной реализацией. При другой реализации их нет.
1. Возможно использование только Forward Iterators. Другие, такие как Reverse Iterator, Bidirectional, Random нельзя.
2. Контейнер содержит только old-plain data. Это тоже очень сильное ограничение, никакие классы, ООП и проч. нельзя использовать.
3. При всей кажущейся оптимальности, данный способ будет проходить по всем элементам, невзирая на то, что можно остановиться на первом элементе. Если же сделать реализацию, чтобы он останавливался, то тогда возникает следующая сложность: а что, если у нас контейнер содержит несколько контейнеров? Что тогда? Как перейти от первого ко второму?
Да, для частного использования частного вида задач это и можно использовать. Но для общего случая этот способ не очень подходит. Поэтому хотелось бы видеть не только идею, но и анализ: когда можно использовать, когда нельзя, какие ограничения. А также в чем выигрыш по сравнению с десериализацией и проверкой в контенере.
1. Нет нормальной защиты муравейника. Она есть, но должна быть гораздо более сильной. На это надо тратить немало времени, чтобы сделать достойную защиту.
2. Нет нормальной атаки чужих муравейников. Опять же, она есть, но надо это делать гораздо более целеустремленно. Этот фактор имеет крайне важное значение в самом начале игры, когда противник слаб и можно быстренько его захватить.
3. Атака/защита должна максимально следовать правилам чтобы правильно расчитывать шансы. У меня алгоритм использует свой анализ и иногда сливает.
4. Сбор еды должен идти постоянно. Чем больше котролируемая территория, тем лучше. Т.е. муравьи должны увеличивать видимую часть территории. Это тоже очень важно. При правильном развитии можно других легко задавить числом.