Отвечаю dalex-у.

А в чем плюсы stdin / stdout то? Вроде input.txt / output.txt строго удобнее.

Во-первых, в файлы можно несколько тестов засовывать, и запускать либо верхний, а остальные тесты тогда сохранены ниже, либо как мультитест, что вообще здорово.

С input согласен. Где здесь профит от output?

Во-вторых, их не надо переименовывать от задачи к задаче, как  * .in /  * .out.

Это я вообще считаю строго неправильным. Одна задача -- один инпут. На тех же кодфорсах, например, довольно удобно иметь свои старые тесты по задаче, если тебя взломали и ты тестируешь решение заново. Не говоря уж о командных контестах, в которых может вестить работа над несколькими задачами одновременно. А если для задачи выделять папку, то появляется бонус в том, что там может жить генератор, скрипт для стресс-теста и подобное, не засоряя остальной контест.

Ну и если уж так нравится stdin, напиши #ifdef на нулевой минуте просто.

Опять же, а) я не хочу тратить на это время, если у меня нет этого в шаблоне, б) если с файлами один контест из десяти, ты скорее всего про это забудешь, с) даже если у тебя шаблон, ты точно про это забудешь, если вдруг зачем-то понадобится сабмитить свежесозданный файл.

Не хватает такого вот аргумента: С консолью проще дебажить. Скармливаем по чуть-чуть инпута или какие-то отдельные запросы, получаем оутпут порционно, думаем, что ввести дальше и тд... Короче говоря, интерактив получается

Нормально. Сейчас свое видение ситуации опишу.

Вообще, вариантов не два, а три: 1) stdin / stdout, 2) input.txt / output.txt, 3) problemName.in / problemName.out.

Сразу пройдусь по третьему варианту. Это худшее, что можно было придумать. Я думаю, что огромное число команд ловили свои RE1 / WA1 из-за того, что забыли поменять файлы. Если кто не понял, происходит это так. Начинается контест, видишь задачу A, там файлы (условно) a.in / a.out. Решил, сдал. Видишь задачу B. Копируешь проект / исходник / класс с задачи A / шаблона или стираешь в ней код и пишешь задачу B. Дальше два варианта.

1. Шаблона нет, и ты вынужден, матерясь, создавать файл b.in руками. Создаешь, теряешь полминуты, сдаешь задачу. И потом еще раз 5-10, в зависимости от сложности контеста, делаешь то же самое. Это в конце концов задалбывает, и ты понимаешь, что с шаблоном-то удобнее.
2. Шаблон есть, и локально все тестируется на input.txt / stdout или input.txt / output.txt. Все работает, сабмитишь, получаешь RE 1. В очередной раз проклинаешь авторов контеста.

В обоих ситуациях надо потратить время на бесполезное занятие — поменять #define TASK "problemName", а в первом случае еще и создать файлы. В случае stdin / stdout или input.txt / output.txt этого делать не надо — все задачи имеют одинаковый формат.

Аргумент о том, что хорошо держать тесты в разных файлах сомнителен. Во-первых, не так уж часто это и надо. Во-вторых, тесты можно скопировать в Notepad++ / любой другой редактор. В третьих, если уж реально надо, локально ты сам себе хозяин, как удобно, так и делай. Пропиши в шаблоне разные файлы для разных задач и будь счастлив. А остальным не надо навязывать. Никто не проиграет от того, что ввод-вывод во всех задачах одинаковый. Но если он разный, всегда случается то, что я выше описал.

Теперь первый и второй варианты. Они тупо эквивалентны, потому что на нулевой минуте в шаблоне в любом случае задается формат ввода-вывода. Если в тестирующей системе используются потоки — не пишешь ничего в #else (комментишь input.txt / output.txt в #else), если используются input.txt / output.txt — пишешь (раскомменчиваешь) их в #else. И все. Маленький плюс (совсем маленький) input.txt / output.txt — они предпочтительнее для тех, кто сам использует input.txt / output.txt, но лишь потому, что такие участники просто экономят несколько секунд на написание #ifdef.

И я еще вот чего не понимаю. ifsmirnov бомбит с того, что не дописал input.txt / output.txt и сабмитнул без них. И при этом он признается, что у него в коде написан #ifdef. Так почему бы их не указать в #else в шаблоне на старте контеста? Это намного эффективнее, чем ручками дописывать input.txt / output.txt перед каждым сабмитом.

Плюсую за stdin / stdout:

Мне кажется это наиболее гибкий вариант, хочешь пиши себе ./a < a.in > a.out, хочешь ./a < a.in, хочешь просто ./a.

Правда, если кто-то привык к какой-нибудь IDE по типу MSVC или Eclipse, то возможно этот вариант не всегда удобен. Я когда использовал MSVC, то использовал вариант input.txt/stdout локально, а тесты к задаче сохранял в конце файла с решением в закомменченной секции. И вариант с problemName.{in, out} мне пришелся бы не по душе по примерно тем же причинам, что dalex перечислил выше.

Мне казалось, любой адекватный участник на C++ просто пишет #ifdef на пару freopen в начале тура (скорее даже перед туром), и забывает о файловом вводе-выводе до конца контеста. Что касается Java — сторонники этого языка вынуждены страдать и писать много лишнего кода, так язык устроен вроде.

Честно говоря, не вижу смысла дальше обсуждать тот факт, что наша система не такая, как остальные. По-моему input.txt/output.txt — это наименьшая из её проблем =(

P.S. Хотя на правах холивара, почему бы и нет =)

Я пользуюсь stdin/stdout локально, потому как удобнее дебажить. К тому же, аргумент "удобнее тестировать, запихнул в файлы тесты и тестишь(пардон за тавтологию)" под Windows 10 не работает — возможность вставки из буфера обмена в консоль сделала своё грязное дело.

Но если думать о людях, которые только начинают своё развитие в направлении ОП, то, наверное, лучше stdin/stdout — ведь чем больше на старте непонятного, тем меньше желания заниматься. Кто-то скажет (наверняка какой-то корифей), что это всего 2 строчки кода, что их просто надо заучить и т.д., но ведь программирование — не та дисциплина, где заучивание работает, верно...?

P.S. всё-таки двойной ввод-вывод лучше, о вкусах ведь не спорят :)

Вот забавное решение случая problemName.in / problemName.out для java:

public class D {
    public static void main(String[] args) {   
      String task = D.class.getName().toLowerCase();      
      String input = task + ".in";
      String output = task + ".out";
      // PUT YOU CODE HERE
    }
}

Например, если вы решили задачу D и хотите написать B, то просто копируете в IDE D.java и вставляйте как B.java. Имена файлов поменяются автоматически, а рантайм ерор напомнит вам создать отсутствующие фалы.

Я предпочитаю использовать stdin/stdout. Поэтому, чтобы избежать проблем с засылкой кода на контестах, где просят problemName.in / problemName.out , я просто добавляю вот такой класс сразу после инклюдов:

#define FILENAME "filter"
struct FileOpener
{
	FileOpener()
	{
		FILE* f = fopen(FILENAME".in", "r");
		if (f)
		{
			fclose(f);
			freopen(FILENAME".in", "r", stdin);
			freopen(FILENAME".out", "w", stdout);
		}
	}
} fileopener;

Это сразу избавляет от необходимости добавлять какие-нибудь дефайны, а также оставлять первые две строки в мейне. Разве что в этом случае тоже есть проблема, можно случайно забыть создать представителя класса, но эта проблема может возникнуть разве лишь в одной задаче :-)