Сейчас читал сообщение в блоге Alex_KPR про Казань и удивился тому факту, что ребята пишут в dev_cpp.
Среды разработки - это интересная тема. Если в случае с вопросом "почему вы используете тот язык, который используете" ответ "привык" будет дан 90% респондентов, то в случае со средой разработки это кажется как минимум глупым - стоимость перехода на другую среду в сотни раз ниже стоимости перехода на другой язык. Значит, выбирая среду, человек чем-то руководствуется.
Если забыть на секунду про финал, где надо работать под Linux, а, следовательно, и выбор совершенно другой, сосредоточимя на средах, доступных для Windows. При этом рассматриваем исключитеьно с точки зрения "кодячить олимпиадки".
Для Java есть несколько сравнительно равных сред - Eclipse, IntellijIDEA, NetBeans - у каждой есть фанаты, которые с пеной у рта будут доказывтаь, что другие две гавно, я работал во всех трех постольку поскольку, и больше работал в Eclipse, потому что это среда на финале. Я не нашел заметного преимущества какой-то из этих IDE для себя, но я и не так чтобы сильно много хотел.
Для C++ я вегда работал в MSVC. Я пытался работать в MinGW, и один раз даже писал контест из Dev-CPP. Может быть у меня были старые версии или кривые руки, но ни ту ни другую я не смог заставить в режиме отладки показать мне содержимое вектора. Так как решение на олимпиаде обычно содержит десятки STL-контейнеров, невозможность отлаживать STL формально для меня равна факту отсутствия отладчика в среде. Кстати, та же проблема существует и в Eclipse CDT, но отладчик в CDT - это отдельная тема. Мы на финале пользовались исключительно Debug Output :о)
Поэтому для меня объективно лучше MSCV. Любой важный для меня старт - отборочные или SRM (срм влияет на рейтинг, а я люблю манчить), я всегда пишу и буду писать из MSVC, потому что на важном старте возможность быстрой отладки для меня критично важна - как бы я не был крут, я все равно буду ошибаться и мне нужен быстрый способ ошибки отловить.
Другой вопрос, когда я пишу для удовольствия - открытые кубки, тимус, сборы. Это интересный момент - мне не приятно писать из студии :о) По ряду причин. Мне не нравится ее перформанс - студия, как и почти любая среда разработки, немного притормаживает - это не критично для работы, но это бееесит. Вторая причина - не очень удобное управление проектом - мне не очень нужен проект для олимпиадки, ведь на олимпиаде единица измерения - это один файл, а не проект. Мне не удобна любая среда разработки, потому что мне не нужен проект, мне нужно уметь быстро переключаться между двумя файлами, над которыми я работаю. Более конкретно - допустим я пишу контест и работаю над двумя задачами (допустим по одной тупняк, я переключился на другую, и периодически меня осеняет, я возвращаюсь к первой, вношу поправки, вруню опять, переключаюсь на вторую, кодячу, меня осеняет, и по циклу - пример редкий, но возможный. Другой пример - когда вы работаете над задачей и над генератором тестов для этой задачи чтобы отловить TLE). В студии мне надо убрать один файл из проекта и добавить другой. Это не удобно и требует очень много лишних действий.
Другая проблема - в MSVC я могу писать только на C++, мне надо переключиться в другую среду, чтобы написать задачу на Java. Надо ли говорить, как работает не очень быстрый компьютер, когда на нем запущено два мамонта-серыд? А старты для фана я всегда пишу на обоих языках, а когда есть поддержка C#, то на всех трех, потому зацикливаться на одном языке не интересно.
Поэтому я для фана пишу в... FAR Manager :о) После установки Colorer и настройки компиляции явы, шарпа и С++ по Enter FAR становится невероятно удобной средой. Приведу причины:
1. Быстрое переключение между задачами - вам надо просто перебежать от файла к файлу в FAR. Учитывая разницу в скорости FAR, который все действия выполняет моментально, и любой среды, которые все-таки притормаживают, в FAR переключиться между задачами одно удольствие.
2. Быстрая смена языка - я могу писать на любом языке, компиляция настроена для всех трех.
3. Не надо коментировать вывод. Формально, когда я работаю в студии (и я думаю многие так делают), я комментирую перенаправление выходного файла, потому что в студии не удобно смотреть каждый раз вывод в файл. Она еще назойливо спрашивает "файл обновился, перегрузить файл" - это вообще бесит. Поэтому я просто отключаю перенаправление. Надо ли говорить, сколько раз в жизни я забывал убрать коментарий и отправлял решение без перенаправления :О) В FAR я просто не убираю перенаправление - там я все равно при компиляции нахожусь в папке и могу сразу посомтреть вывод.
4. Использование экрана - редактор в фаре дает в ваше распоряжение весь экран. В студии конечно можно убрать все окна, но это не тоже самое - в FAR при этом все инструменты остаются доступны. Если я в студии уберу Solution Explorer - это будет копыто. Фар показывает больше кода, и это удобно.
Минусы тоже есть, и самый главный из них - отладчика-то нет :о) Приходится использовать Debug Output. Есть люди, которые говорят, что используя Debug Output могут отлаживать не медлененее чем я в студии. Это бред сивой кобылы :о) Сравнивать крутой отладчик и Debug Output нет смысла - второй всегда будет заведомо медленнее.
Кроме того, поначалу немного бесило отсутствие IntelliSence, но это нафиг не надо, когда языки уже все позубрил достаточно хорошо. Это критично, если Java - не основной язык ,но надо закодячить что-то на длинную арифметику, так как в этом случае можно не знать на память какие-то вещи, которые автодополнение заполнит. Но после пары лет кодячанья это нафиг не надо, потому что все итак знаешь.
So, this is my story :о)
Немного не объективной статистики. В петрозаводске доминирующее большинство команд писало в FAR когда я был там последний раз. Бурундуки, Орел с Жуковым, и многие другие. Не все, конечно, но реально очень многие.
В Ижевске на сборах - где даются задачи из ПТЗ, но приезжают топ2 команды, в FAR не писал вообще никто :о)
Так что тема для обсуждения - какие среды Вы юзаете для каждого из языков, и почему?
Есть люди, которые говорят, что используя Debug Output могут отлаживать не медлененее чем я в студии.
Задачка на сообразительность: курсор выполнения стоит перед кодом vv.push_back(foo(pq.top())); и что надо сделать, чтобы зайти в foo? А то Microsoft скромно предлагает нам протестировать и их реализацию STL тоже (а мы хотим?).
Сравнивать крутой отладчик и Debug Output нет смысла - второй всегда будет заведомо медленнее.
Выделено полужирным, for great justice
Когда в последний раз писал олимпиаду в среде Borland C++ Builder, ощутил невероятную лёгкость. Не знаю, как это было настроено, но среда задала вопрос: "создать для вашего cpp файла проект с настройками по умолчанию?"
Проблема в том, что BCB6 заметно устарел, и для каких-то других целей его покупать бессмысленно, а покупать его только для олимпиадок - это дороговатая роскошь. Вариант использовать пиратское ПО я не рассматриваю в принципе.
Студия же есть бесплатная - Express, которой хватает для олимпиадок. Это плюс в пользу студии vs BCB6 :о)
либо как сказал FatalErr, либо, что быстрее (без всяких брекпоинтов) - встаем на первую строку Foo и Ctrl+F10
dev-cpp - очень неплохая "олимпиадная" среда разработки. В ней нет навязчивых проектов, долгих запусков, работающих с вероятностью 50% обновлений аутпута (как бывает, скажем, у MSVC). Не нужно добавлять и удалять файлы при смене задач, как было описано выше. 4 года я в dev-cpp и никогда на неё не жаловался.
Главный аргумент против dev-cpp - её неумение ставить отступы. Это легко лечится настройками редактора, просто снимаем галочку с "умной" табуляции.
именно 4.9.9.2 :)
я использую исключительно debug output, поэтому подобных затруднений не испытываю
Для важных стартов, имхо, отладчик нужен обязательно.
для утешительной задачи будет достаточно пары строк debug output
на написание "for(int i=0;i<n;i++) cout<<i<<": "<<a[i]<<endl;", компиляцию и запуск уйдёт не намного больше времени, чем на копание в отладчике
Уже где то 2 года для олимпиадного программирования использую связку 'Total Commander' + 'notepad++'. Попробую вкратце перечислить плюсы и минусы, некоторые из которых будут пересекаться с приведенными выше.
+:
1. Папка с задачей состоит из 4ех файлов - исходник, бинарник, входной и выходной файлы. Соответственно папка всего контеста - из набора папок с задачами.
2. Абсолютно всё управление ( создание папок, файлов, компиляция, переключение между файлами в блокноте, execution и тд) возложено на горячие клавиши. Это очень быстро и удобно. При этом для работы с одной задачей (кодить, запускать, смотреть вывод) вообще не требуется покидать блокнот.
3. Имя входного/выходного файла нужно писать только однажды. После чего выделяем это имя в тексте и жмем Ctrl+shift+F8 - и этот файл уже создан и открыт в блокноте :)
4. Стимулирует искать ошибки глядя в код, а не ковыряясь в отладчике.
5. Вся эта связка является portable, и запускается прям с флешки (компиляторы с блокнотом запихал в папку Total Commander)
-:
1. Как сказано Александром, нет дебаги :) приходится писать кучу всякого вывода, и потом не забывать его отключать.
2. Нет возможности узнать код возврата в случае аварийного завершения. Опять таки приходится втыкать всякий вывод чтобы понять, где же свалилась прога (частично лечится с помощью assert).
3. Суммируя 1 и 2, на поиск некоторых дибильных ошибок уходит много времени.
4. Нет Java (впрочем можно и её настроить, наверно :).
5. Нет возможности использовать на официальных соревнованиях.
С плюсами и минусами всё. По поводу FAR. Сначала я пытался для этих целей настроить именно Far, а не Total Commander. Но рассмотрев кучу всяких плагинов (некоторые еще и конфликтуют друг с другом), я так и не смог в полной мере достичь нужной мне функциональности (уже точно не помню, чего же именно мне не хватало в этой функциональности).
Недавно вот узнал про наличие в студии Call Stack :) И не долго думая переписал assert так, чтобы на нем останавливался отладчик. Т.е. если что то падает на assert (при умелом использовании это самая частая ошибка), то можно узнать не только номер строчки, где находится этот вызов ассерта, но и всё состояние проги на этот момент. А на мой взгляд самое главное назначение дебаги именно в этом - рассматривать значение переменных в "предсмертном" состоянии программы. Так что с недавних пор пишу задачки преимущественно в студии. А вот для создания своих собственных задач (написание чекеров, генераторов тестов и тд) описанная связка остается незаменимой.
Вообще в плане удобства написания и отладки из известных мне сред больше всего нравится Eclipse SDK. Впрочем это в некоторой мере относится к языку программирования Java, его возможностей, а не к самой среде. Но не перехожу с C++ на Java только по той причине, что программы на Java безнадежно проигрывают по времени (зачастую и по памяти) тем же программам, написанным на C++. А в условиях реального соревнования писать одно и то же решение сначала на Java, а потом на C++ (по причине TLE), не является хорошим тоном...
Моё мнение - почему нельзя писать в среде, хотя бы по причине более адекватного редактора? :)
Да и дебаг спасает при необходимости. На тренировках можно просто не разрешать себе пользоваться отладчикам, если это настолько волнующий момент :) Я думаю, из присутствующих здесь контролировать свои действия могут все ;)))
Я пользуюсь Visual Studio. Eclipse знаю не очень, пока от него только раздражение и как следствие отсутствие желания изучения :) Приходится частенько работать в Eclipse-производной ZendStudio, поражает обилие идиотских, по-другому не скажешь, багов. Не знаю, правда, идут ли они от ядра Eclipse или это уже качество мануфактуры Zend...
+ копирование проектов по ctrl+C ctrl+V
+ автоматический билд
+ удобное окошко с выводом
+ можно запустить перебор по одной задаче и одновременно кодить или отлаживать другую, всё не вылезая из среды
Например, если мы скопипастили строчку вида:
поменяли x1 на y1, а queueX на queueY поменять забыли, получив:
то среда разработки в месте, где объявлена queueY, покажет, что она используется только для записи, но не для чтения. Эта фича, например, Eclipse, несколько раз помогала не делать лишнего неверного сабмита за минуту, скажем, до конца соревнования.
А вот с этой фишкой история сложнее. Eclipse запускает не старый билд, а текущий. Сообщение же об ошибке компиляции встраивается в код в том месте, где оно имеется, и благополучно вываливается в консоль при первом исполнении этих строк.
Все было хорошо до того, как мы на полуфинале посадили баг в принципиально неисполняемый кусок кода. Это было в задаче про базу данных, и исправлялись базовые процедуры ввода-вывода. В результате при прогоне на тестовых примерах никаких ошибок никто не выдавал, правильный результат записывался в файл, и т.д. Конечно, ошибка подсвечивалась в редакторе, но была не в поле зрения (базовый ввод-вывод у нас в конце файла). Поэтому с легкой душой мы отсабмитили код и получили CE.
В общем, вдогонку к предыдущему своему сообщению. Да, emacs тоже вполне допустимый вариант. Подцветка есть точно для следующих языков: C++, Java, Pascal (да там и его предшественники есть типа Ada). Речь идет о версии 21.3 emacs, если что.
Отступы и разметка там тоже есть, более того, если что-то вдруг не так, можно выделить проблемный регион и снова отформатировать отступы одной команды (аналог Reformat в Visual Studio).
Что касается того, чтобы скомпилировать и запустить. Я лично создал в директории makefile, из emacs его можно запустить на компиляцию и в отдельном окне компиляции смотреть выводы, чего там может быть не так. В принципе вполне хватает. Для перехода между разными окнами (буферами в их терминологии) тоже простые сочетания клавиш используются. То, что на порядок быстрее сборок и компиляций в той же Visual Studio или Netbeans - это, я думаю, и так понятно. Так что вполне вменяемый аналог FAR и Total Commander, тем более что в Линуксе скорее всего придется использовать его.
Забыл сказать про недостатки сразу же. Во-первых, нет по умолчанию модуля для расцветки и форматирования для C# (сейчас рыскаю по инету, может, и найду). Кроме того, лично у меня проблема с русскими буквами, он там поддерживает какие-то странные кодировки типа Cyrillic-ALT и прочие, у которых другая раскладка клавиатуры, по ходу. Сейчас ищу нормальный шаблон Cyrillic, чтобы работал.
В принципе русские буквы на олимпиадных соревнованиях не сильно-то и нужны, если только в комментариях, да и там транслит использовать можно или писать на английском.
proofpic
Люди вон выигрывают чемпионат мира на Free Pascal =)
Разве на ACM ICPC вообще доступен FP? Гена, насколько мне известно, на FP писал IOI, а где-то в 2012 — 2013 переключился на C++ (по крайней мере здесь, на CF).
Ну так сообщение же датировано 2010 годом.
Ой. Лол. А я и не посмотрел на даты. Да, пора переставать встревать в любые дискуссии, что вижу в "прямом эфире" %)
F9, C, A
Там добавить две записи.
Для расширения *.java
"C:\Program Files\Java\jdk1.6.0_18\bin\javac.exe" !.!
Тока путь поменять на свой
Для раснирения *.class
java !
там Insert;
маска "*.java";
описание любое;
команда на Enter: "javac !.!";
(ну или C:\Programs\...\javac, если компилятор не в путях).
дальше OK, Esc, и всё должно работать.
Также можно сделать с "*.class"-файлом, чтобы он запускался по Enter. Для него команда будет примерно такая: "java -cp . -Xmx 256M -Xss 64M !"
Ещё, если в каком-то месте что-то непонятно, можно нажать F1 и почитать.
Для С++ использую "codeblocks"
Плюсы:
1. подходит и под Linux
2. бесплатно!
Минусы:
1. надо проекты создавать
Что я делаю не так?
Как сделать так, чтоб в "Far manager" при создании файла "*.срр" в нём уже был мой темплейт?
Дома пишу в Sublime Text 2 и компилирую исключительно руками из терминала. Для отладки — debugging output.
Благодаря этому легко могу переключаться между ОСями или редакторами (хотя фич Саблайма на онсайтах нередко не хватает, по привычке пытаюсь использовать множественное выделение или ещё что такое), к тому же я всегда знаю, как именно компилируется мой код. Вообще способность более-менее ориентироваться в шелле нередко бывает полезной на контестах, для того же автоматизированного тестирования, например.
Зачем на контесте нужна IDE, если честно, не понимаю. Кода у нас мало (и всё в одном файле), так что компилить совсем не сложно. Автокомплит бывает полезным, но редактор с поддержкой автокомплита — не обязательно IDE :)
P.S.: а, да, из того, что обычно доступно на онсайтах, обычно использую gedit (Linux) или Notepad++ (Windows), благо они простые, быстрые и более-менее удобные. Когда-то использовал Geany, но всё-таки не люблю доверять компиляцию/исполнение среде, да и притормаживает он на некоторых тачках.
Не удержался — написал. Авторы двух последних комментариев — чем они заслужили столько минусов? Тем, что подняли тему 3годичной давности? Или Вы их недолюбливаете за что то?
Менее логичного "слития кармы" я еще не видел.
время показало я был не прав :)
Так в чем же сила?:)
В привычке ;)
"... а сила в правде".
А по теме: какая нафиг IDE? Что из возможностей IDE пригождается вообще? Автокомплит (самый простой) есть везде: vim, emacs и даже far edit. Extract, refactor, inline var, encapsulate — некоторые олимпиадчики даже не знают значения этих слов. Встроенные методы тестирования, профайлинг, системы контроля версий, build скрипты... Максимум, что нужно — это макрос в стиле
nmap <F2> :!g++\ %\ &&\ ./a.out
.На джаве пробовали писать в FARе?
Нет, но когда нужна магия биг-интейжеров я писал на Vim. В итоге выходили строки по 200 символов в ширину, но разве это скорее моя проблема, чем редактора.
"Самый простой" автокомплит чаще раздражает, чем помогает, т.к. постоянно предлагает подставить то, что абсолютно не подходит в данном контексте (например, хочу вызвать метод одного класса, а предлагаются методы другого, переменные и все остальное, начинающееся с введенного префикса). И автокомплит редактора не позволит вызвать метод, название которого ты не помнишь, IDE же просто покажет все методы класса (а возможно, и краткую документацию к ним).
Использую Microsoft Visual Express C++ 2013 с темной схемой
На самом деле очень удобно использовать проект. В проекте у меня находятся файлы main.cpp, in.txt, x.h (шаблон), a.h, b.h... На контесте посылаю h-файлы в качестве решений.
Быстро переключаться между ними — ctrl+tab. solution explorer не нужен.
Горячие клавиши очень удобны. Создать новый проект — ctrl+shift+n, создать новый файл — ctrl+shift+a
В main.cpp у меня находятся всего две строчки
В a.h при этом будет
Это очень удобно — вывод всегда будет идти на экран, но никаких действий перед отправкой осуществлять не надо
Кроме того, можно сконфигурировать начальный проект так, чтобы при создании нового проекта сразу же создавались нужные файлы (для этого необходимо открыть дефолтный проект Program Files/Microsoft Visual Studio x/VC/VCWizards/default.vcxproj). Создаешь новый проект — а там уже шаблон твой лежит, удобно. А еще в настройках проекта уже стоит игнорировать ворнинги 4996 (deprecated-методы)
А возможности отладки конечно же в этом IDE самые лучшие. И все окна можно настроить на свой вкус.
В MSVS можно обойтись без freopen("in.txt", ..) :