1. Тема письма должна быть четко структурирована по следующей форме:
группа Фамилия задача [версия]
например
108 Иванов матрицы 4 [2]
В данном контексте предполагается, что ранее Иванов уже присылал решение этой задачи 4 из раздела ``матрицы'',
и теперь присылает переработанный вариант под версией 2.
Каждая задача присылается отдельным письмом.
Письма с решениями, в которых тема не соответствует указанным правилам, рассматриваться не будут.
2. Для проверки каждый раз присылается необходимый и достаточный набор всех файлов для проверки. Это означает, файлы с исходным кодом (c, cpp, h), файлы с тестовыми данными для проверки работоспособности. файл с описанием процедуры тестирования (как компилировать, как запустить, что вводить, где увидеть результат и т.п). Другие файлы (служебные файлы и каталоги проекта конкретных систем программирования) присылать не надо. Если файлов много, можно (и желательно) их упаковать общепринятыми архиваторами (zip, rar).
3. Решения стоит присылать заблаговременно перед очередным семинаром, чтобы я их успел нормально проверить. Заведомо не будут проверяться работы, присланные после 20 часов накануне семинара.
4. Проверка присланных решений проводится по следующей методике:
- проверяется наличие файла с описанием процедуры тестирования;
- файлы компилируются в соответствии с описанной схемой, но с жесткими настройками компилятора;
- запускается тест в соответствии с описанной схемой;
- анализируются полученные результаты, в соответсвии с описанной схемой.
Если на этих этапах возникает какой-либо сбой (нет описания схемы тестирования, ошибки компиляции,
непонятное и неописанное поведение программы, программа "падает" и т.п.), то проверка, как правило, прекращается.
Если все проходит нормально, то анализируется код на предмет его стиля, использования конструкций языка,
реализации алгоритма и т.п. Здесь задача может быть отклонена по причине несоответствия
базовым требованиям к коду.
Возможно, далее запускаются тесты на других данных.
В итоге формируется ответ по результатам проверки, который обычно либо принимает программу, либо описывает сушность
первой критической ошибки.