Все раунды в Топкодере для меня делятся на две категории: код работает сразу и не работает вообще. Если код вдруг сразу не работает, то начинается просто вынос мозга. Поделитесь как удобнее всего писать в ТС, какие плагины (Kawigi не очень) и самое главное как дебужить код в Топкодере (говорят даже можно как-то объединить арену и Visual Studio). Заранее всем благодарен особенно если напишите как всё хорошо настроить.
dbg(x) cerr << #x << " = " << x << endl
аналогично для контейнеров и для массивов и получается более менее информативно а чтобы не коментить можно делать что то вроде
#define DBG 1
#define dbg(x) {if(DBG)...}
но это конечно дело вкусса... вобще есть
http://forums.topcoder.com/?module=Thread&threadID=597911&start=0
вполне хороший плагин кажеться =) к нему есть подробная инструкция ещё я видел что кто-то сделал для него модификацию по вырезанию не используемого кода... но сейчас с ходу не найду
Ну я долго упирался против плагинов и использовал дебаг-вывод, но в итоге сдался, потому что это жесть - уйму времени надо потратить, в то время как в отладчике можно устроить тот же дебаг-вывод, только интерактивный, - не вводя никаких имён переменных, и не придумывая, как же так удобочитаемо вывести :)
Поставил Kawigi Plugin - во-первых, с ним быстрей проверка семплов, во-вторых - он сохраняет на диск исходник программы вместе с генерилкой семплов, что позволяет мгновенно переключаться на отладку в студии. С этим плагином есть небольшие тонкости в настройке, если компилить будешь вижаковским компилятором, а если есть mingw - думаю, всё сразу должно заработать
Возможно повторюсь, но скажу, что мой тренер считает, что каждая лишняя написанная строчка кода -ещё это одна потенциальная ошибка.
Я с ним в этом полностью согласен. Если уверен в эффективности библиотек - зачем тратить и время и набирать код, который скорее всего сходу не заработает?
Вот делать Вам больше нечего, чем изобретать велосипеды там, где нужна скорость реализации, а не раскидывание понтов в стиле : "Смотри, какое крутое дерево я написал."
Если перейти ближе к нашей тематике, то есть задачи, а есть упражнения. Чтобы решить задачу, надо думать, чтобы решить упражнение его надо сделать. Так вот лично я не люблю делать упражнения вроде написания списка или быстрой сортировки, поэтому от паскаля я давно отказался. Мне интересно придумать алгоритм, а уж как его реализовать это дело десятое, чем проще и быстрее, тем лучше. И даже не потому, что багов совершаешь меньше , а потому что писать код не интересно, и надо побыстрей это противное занятие закончить и перейти к приятному - обдумыванию решения следующей задачи :)
А ввод/вывод, наверное, через ассемблерные вставки.
Пара мыслей по всему прочитанному.
Имхо, для человека, начинающего заниматься олимпиадным программированием, имеет смысл писать руками почти все алгоритмы. И сортировку в том числе. Почему? Чтобы понять принцип работы. Пример с сортировкой очень уместен. Квику полезно знать, чтобы в дальнейшем искать к-ую статистику за линию. Heapsort стоит писать, чтобы понять суть работы с кучей. Merge sort - принцип разделяй и властвуй. Потому что как ни крути, большинство задач - это варации на различные темы. Знаешь устройство структуры данных - научишься ее применять. Я долгое время писал heapsort руками. Это 3 минуты времени.
В дальнейшем разумеется необходимо использовать возможности языка. Потому как те же упомянутые 3 минуты - это драгоценнейшее время. Задачу сдать можно.
Правда в моей практике не редко бывало, что переписывание стандартных вещей типа hash_set, sort или vector <vector <int> > ручной реализацией давало АС, вместо TL.
Абсолютно согласен.
Про vector <vector <int> > улыбнуло. :) На прошлом полуфинале например не прошло решение с vector < string >, но прошло с char mass[100][100].
А что, даже sort переписывали вручную или это просто как пример?
> А если бы была возможность кидать условия задачи в компилятор,и он сам бы печатал правильный код,то вы бы её тоже юзали
Разумеется. Огонь же ты палочками не разжигаешь. А еще с выходом этой программы бы вымерли сразу соревнования по программированию, а спустя время и программисты как класс.
Я очень сильно сомневаюсь в том, что какие-то абстрактные скилы действительно растут от того, что ты кодячишь одни и теже алгоритмы кажрый раз заново. Я уверен на 100%, что все вышеперечисленные алгоритмы после 10-ого раза ты пишешь уже не думая, потому что ты их пишешь каждый раз заново. Так что единственный скил, который ты гипотетически можешь повышать - это скорость набора. Может если ты после IOI хочешь работать секретарем, то она тебе поможет. На соревнованиях она показала себя как не решающий фактор :о)
Я тебе открою еще ужасный секрет - у очень многих из тех кто пишет топкодер и кодефорс и другие онлайн соревнования - О УЖАС - есть текстовые файлики с самыми популярными алгоритмами, которые не входят в стандартные библиотеке - КМП, потоки, еще всякая шняга с графами, НОД, 2-сат, которые они копипастят в решения. Потому что это нормально хотеть решать задачи, а не кодячить один и тот же код сотый раз.
Ну и еще конечно манера спорить ваша заслуживает отдельного упоминания :о)
Фар быстрее запустить, в фаре быстрее переключаться между файлами. Когда любое действие выполняется за нулевое время (в отличие от любой среды), пользоваться продуктом гораздо приятнее.
Помимо скорости, и более удобного управления файлами с задачами, думаю сложно найти плюсы. Надо просто попользоваться и почуствовать разницу. Я пишу почти все в FAR и объективного объяснения я этому не вижу :о)
Потому что на полуфинале мне не важно, как быстро работает интерфейс, мне важно как быстро я могу получить результат. И, так как отлаживать дебажным выводом менее эффективно чем пошаговым, я не вижу никакого смысла писать полуфинал не в студии.
А теперь, когда мой последний полуфинал далеко позади, и писать можно не спеша, тип отладки не решает. Поэтому можно писать в том, в чем приятнее. А в FARе приятнее писать :о)
Из плагинов юзаю только Кавиги.
250 - пишу сразу в арене. Если не получается - значит, весь раунд насмарку.. ибо, что это за фигня - закопаться с 250 :(
остальное все по ситуации. часто копирую сразу класс в Студию (у меня там для этого всего есть шаблон) и пишу в ней. Времени экономится море, а тратится - только на пару копирований и запусков тестов. Иногда, когда задача не заключается в стопицот строках кода, пишу прямо в Кавиги.
На самом деле, Кавиги - весьма удобная штука. Главное, правильно ее использовать.
P.S. пробовал ставить другие плагины, автоматически инклюдящие код в Студию.. оказалось, что это очень неудобно, потому что генерится куча лишнего кода, который очень сильно отвлекает. Никакого смысла, на мой взгляд, это не несет.
а экономия - два копирования. ты долго нажимаешь crtl-c / alt-tab / ctrl-v ?
ты долго нажимаешь crtl-c / alt-tab / ctrl-v ?
=)
как говорится, привычка - вторая натура
Хорошо. 2 раза ctrl-c + alt-tab + ctrl-v.
Лично я так делаю. Кстати, а куда имено кавиги сохраняет код?
http://www.topcoder.com/contest/classes/ExampleBuilder/ExampleBuilder.html
Кстати, сгенеренный код можно изменить в настройках и оставить только шаблон главного метода, если тесты действительно не нужны.
FileEdit + CodeProcessor + любой плагин для автовгона тестов (я юзаю TZTester) это must have в арене, так же как и Кавиги. Причин НЕ поставить плагины я просто не могу придумать.
То, что дебаговый вывод всегда лучше пошаговой отладки - это булшит. Утверждение многих людей, что они быстрее напишут дебаговый вывод, чем я отлажу пошагово - это тем более булшит.
Это два совершенно разных способа отлаживать. Дебаговая отладка просто дампит кучу данных. Пошаговая отладка позволяет вам пройти каждый шаг с вашей программой.
Есть тонна сценариев, где не работает одна, и где не работает другая. Если мне надо быстро проверить есть ли ошибка в строке, я нажму Ctrl+F10, F10 и наведу мышку на переменную, и никто никогда меня не убедит, что написать дебаговый вывод в этом сценарии быстрее и проще. Аналогично, чаще проще сделать conditional breakpoint и пройти потом пару шагов с кодякой, чтобы быстро понять правильно ли работает сценарий.
Аналогично в обратную сторону, никто никогда не будет использовать обычный отладчик, если надо посмотреть содержимое динамической таблицы, потому что ни один известный мне отладчик не умеет красиво выводить двумерный массив. Особенно отладчик в студии. Особенно когда надо еще какую-то дополнительную информацию отследить, или вывести как таблица меняется постепенно.
Для полуфинала скил должен быть очень высокий в обеих отладках. Мы на полуфинале писали в студии, и я всегда очень круто умел отлаживать встроенным отладчиком.
На финале в C++ будет эклипс, а значит если используется С++, то про отладку обычную можно забыть, поэтому в том чудесном слуаче, если вы прошли на финал, надо после полуфинала только уже начинать надрючиваться на дебаговый вывод.
А желание людей всегда юзать дебаговый вывод и писать в каком-нибудь виме вместо студии - это не правильно. Я сам некоторое время готовился к полуфиналу тренируясь в фаре, и фар на полуфинале не заменяет студию ни в каком месте. И вим тоже не заменяет. На финале я согласен что вим возможно лучший вариант из имеющихся. Но финал как я уже сказал это крайний случай, который до декабря в принципе не важен.
Не рассмотренный мной вариант "не отлаживать вообше, а писать правильно" работает только для избранных ,в число которых мне не повезло попасть :о)
Я кстати извиняюсь, что я тему про топкодер перевел на полуфиналы и финалы :о Это из-за надвигающегося сезона.
В любом случае все вышесказанное на топкодер отлично распространяется - особенно в 250 часто бывает одну строку отдалить очень нужно .и там дебаговый вывод будет просто потерей времени.
Я использую плагин для Eclipse - EclipseCoder (Java)
Тут тебе и привычная среда Eclipse с отладчиком и т.п. + удобное чтение условия (мне не очень нравится читать тексты в самой Арене) + автоматическое создание JUnit для тестирования. В общем полная интеграция информации из Арены в Eclipse.
1) убирает лишние @Override-ы (на ТС java 1.5) - в ReTester у меня с этим были проблемы;
2) в случае exception'а - не вываливает все в консоль, а грамотно в JUnit'e показывает, где на какой строке произошла ошибка
3) все тесты записаны в отдельном файле (class_nameTest.java) - то есть в файле программы нет ничего лишнего;
4) при наведении на название метода в тесте (в файле class_nameTest.java) проверяет на правильность именно этот тест;
5) легче всего устанавливается;
Из минусов:
1) плохо работает с Eclipse Helios - для тестирование приходилось заходить в файл class_nameTest.java и запускать проект оттуда. Но с Galileo и Ganymede проблем не было;
2) JUnit есть только для java - в случае с с++ просто в консоли пишется passed/failed
В общем, кому интересно - вот инструкция по установке http://fornwall.net/eclipsecoder