WW #3

[antonenko.mixail]

Я не очень понял, зачем вручную освобождать память, когда умираешь. Система же обычно делает это.

[Святослав Власов]

Корректность -- 0/7. Не реализовано консольное приложение.
Дочитай и сделай задание до конца.

Стиль -- 0/3

1. Инклюд гарды?
2. Пробелы вокруг арифметических операций? Прочитай внимательно абзац "Про стиль" на ​https://emkn.ru/courses/2020-autumn/2.20-lang_c_low_level_programming/
3. free(NULL) -- бессмысленная операция.
4. l <<= 1, круто что ты знаешь семантику побитового сдвига, но лучше писать l *= 2
5. Длинные строки (>80 символов) лучше разбивать на несколько.
6. Давай для переменных вроде l, u1, u2, v1, v2, p1, p2 придумаем более говорящие имена. Если l у тебя обозначает длину промежутка, то лучше назвать её length или chunk_size, вместо u и v лучше использовать up/bottom или left/right. Для остальных переменных тоже стоит придумать более говорящие имена.

[Святослав Власов]

Я не очень понял, зачем вручную освобождать память, когда умираешь. Система же обычно делает это.

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

[antonenko.mixail]

Удивила часть про консольное приложение. Почему-то svn проигнорировала main.c.

1. Инклюд гарды.
2. Теперь.
3. Да, есть такое.
4. Хорошо.
5. Хорошо.
6. Пока что не делал.

Да, вопрос в такой постановке действительно тупой. Видимо, я думал про free в main'е, когда это писал.

[antonenko.mixail]

6. А не вариант просто рядом с объявлениями пояснять, за что отвечает та или иная переменная? Мне казалось логичным делать длины имён пропорциональными времени жизни; ну да и плотный код с переменными, каждая из которых занимает половину строки, тоже тяжело читать.

[Святослав Власов]

Корректность 0/7

1. Валгринд рассказывает про definitely lost bytes -- формально это сразу 0/7.
2. Вызов программы с пустым списком приводит к крашу

Стиль -- 0/3

2. По прежнему не вижу пробелов вокруг арифметических операторов.

5. По прежнему вижу строки по >100 символов
6. Верно, что чем короче время жизни переменной, тем меньше можно заморачиваться по поводу её имени, но когда на небольшом участке кода у тебя скапливается куча переменных с именами вроде u1, v1, p2, l, m, a и т.д., это сильно понижает читабельность кода. Такого нужно избегать. От того, что ты u1 и v1 заменишь на left_1 и right_1, твой код сильно не разрастется, но читаемость повысится в разы. Сделай имена переменных более осмысленными.
7. Твой вариант создания массива строк с поиском максимальной длины и копирования строк в один большой массив избыточен. Это оверхед по памяти (представь тест где одна строка длиной в тысячу символов и тысяча строк длиной в 1 символ) и бессмысленное лишнее копирование самих строк. Вместо этого сделай так, чтобы в в массиве хранились не сами строки, а указатели на них, и чтобы сортировались тоже указатели, а сами строки в памяти лишний раз не перемещались.
8. Функция должна называться mergesort, а не my_mergesort.

[antonenko.mixail]

1. Не получилось воспроизвести.
2. Исправлено.

2, 5. Может быть, теперь.

6. Готово.
7. Готово.
8. Я бы и рад, но компилятор жалуется на клэш со стандартной библиотекой.

[Святослав Власов]

Всё ок, с бонусом 11/11

Единственное замечание -- копировать строки в отдельный массив избыточно. Можно было просто передать argv в mergesort.

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

[antonenko.mixail]

Да, шизофренично вышло.