Как эффективно отлаживать программы, используя g ++ и vim в конкурсе ACM?
Vim — это просто редактор, а не IDE. Интересно, как программисты, которые используют vim в конкурсе ACM, отлаживают свои программы? Просто напечатайте «cout», чтобы распечатать некоторую информацию на экране, а затем удалить ее? Или используя «assert.h»? Я чувствую, что это неэффективно, или я просто незнаком с vim и g ++.
Надеюсь, что кто-то может ответить или дать мне несколько советов. Спасибо!
Решение
Поскольку конкурс оценивается на основе правильных решений, представленных за наименьшее количество времени, важно прочитать все проблемы и решить, какую проблему легче всего решить с наименьшим количеством мысли и кода. Эта проблема обычно задается сильнейшему программисту (участнику А), который сидит один за машиной и начинает реализовывать решение, проектируя на лету. Следующие две проблемы ранжирования решаются на бумаге двумя другими участниками (B и C). Алгоритмы заменяются двумя другими участниками для ознакомления. Если обзор удовлетворительный, оба работают над выполнением одной и той же задачи на бумаге. Если A еще не завершена с машиной, следующая проблема решается на бумаге с помощью B и C. К этому времени A должна быть завершена с кодированием решения и отправлена. B может начать реализацию одного из решений на машине, в то время как A и C следуют аналогичному процессу совместной работы, как описано ранее, для решения оставшихся проблем.
Это означает, что, хотя отладка на машине важна, более важно иметь возможность логически обосновать правильное решение на бумаге таким образом, чтобы его можно было легко преобразовать в код. Это то, что должно практиковаться командой до участия в конкурсе, и именно это будет иметь решающее значение для победы в конкурсе.
При отладке программы на машине используйте утверждения и stderr/cerr выход. Таким образом, вам не нужно тратить время на вычеркивание отладочных операторов перед отправкой решения. Однако использование подходящего макроса для операторов отладки, чтобы их можно было легко отключить, может быть полезным, если вы добавили операторы отладки в критический цикл.
Еще одна ловушка конкурса заключается в том, что, хотя решения с использованием грубой силы часто приводят к превышению лимита времени выполнения вашей программы, также не стоит искать наиболее оптимальное решение. Вам просто нужно решение, которое лучше, чем грубая сила. Если оптимальное решение не будет быстро и легко понято как минимум двумя членами команды. Более простое решение, которое является менее оптимальным, обычно может быть отлажено быстрее, чем оптимальное, но более сложное решение.
Другие решения
Это может зависеть от операционной системы, но в Linux вы можете запустить gdb отладчик изнутри vim (или внутри emacs с M-x gdb). Для соревнования, и для повседневной жизни программиста, вы необходимость быть знакомым с вашим gdb отладчик.
добавлений
Если gdb не доступен, я думаю, что люди будут использовать assert.h или отладка printf или же std::cout (или же std::clog) выход.