альтернатива физзбаззу

[avva]

Цитирую из подзамочной записи с разрешения автора, который работает в американской компании и интервьюирует программистов:

Интесная закономерность выявляется. Мы начинаем интервью с того, что просим кандидата прочитать вот такой код, и сказать, что он делает. Как бы он назвал эту функцию?

private static int ok(int a, int b) {
   while (a >= b) a -= b;
   return a;
}

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

Comments

[dism.livejournal.com]

В каком плане разделении?

[d-ohrenelli.livejournal.com]

Проще не бывает.

Задача:

Написать программу на языке С, которая принимает через командную строку 3 имени файла
и переписывает из первого файла все четные строчки во второй файл, а нечетные - в третий файл соответственно.

Дополнительные требования к задаче:
программа не должна падать.
программа должна работать корректно.
программа должна работать относительно быстро.

Писать надо на бумаге.
Справка ко всем стандартным функциям файлового ввода вывода - на столе.

Заваливаться там действительно негде, а поди ж ты - то у кого-то программа работает только с четным количеством строк(а на нечетном падает), то кто аргц не проверит и соответственно упадет, кто последнюю строчку не выдаст ...

[dism.livejournal.com]

Сто лет не писал на си, пошел почитал reference и написал. Не на бумажке конечно, да. :)

Забыли проверить argc - ну окей, это можно понять. Но что за проблемы возникали с последней строкой и как можно падать на четном/нечетном количестве строк мне прямо трудно представить.

Я писал самый-самый тупой вариант:
- проверили аргументы
- открыли файлы
- завели буфер
- завели счетчик с единицы
- цикл пока fgets возвращает не NULL
- если значение счетчика четное - пишем в четный файл, иначе в нечетный
- инкрементим счетчик
- после цикла закрываем файлы

Навскидку в такой реализации есть одна проблема - нужно как-то переписывать чтобы нормально работало на "очень длинных строках".

[d-ohrenelli.livejournal.com]

У вас действительно проблема с длинными строками и (скорее всего) с переполнением счетчика строк на очень больших файлах.
Условие корректной работы не выполнено, увы.

[dism.livejournal.com]

Ну я не пытался выполнить все условия, я пытался наступить на описываемые грабли - и не понял где люди на них наступали. :)

А с переполнением счетчика проблем нет - он переполняется, конечно, но четность/нечетность не сбивается ;)

[d-ohrenelli.livejournal.com]

Если он беззнаковый, то да.
А если он просто знаковое целое - то по стандарту если я правильно помню получаем неопределенное поведение.
Я поэтому и написал скорее всего.

[dism.livejournal.com]

Да, черт, в стандарте и правда UB, а у меня был знаковый int. :)

[d-ohrenelli.livejournal.com]

Плюс ко всему если вашу программу скомпилировали на gcc с опцией -ftrapv то оно таки упадет.

[dyak.livejournal.com]

а если по одному char писать это будет соответствовать требованию относительно быстр? В смысле:
проверили аргументы, открыли файлы, проверили, что открылись, потом
odd = true;
вечно циклим:
если odd, читаем и пишем в третий, а если конец строки то еще и odd = false;
если не odd, читаем и пишем во второй, а если конец строки то еще и odd = true;
при чтении и письме проверяем все ли ОК, если нет, break
закрыли файлы
profit

[d-ohrenelli.livejournal.com]

Вообще требование об относительной быстроте решения было предлогом к вопросу "А почему вы считаете что это будет относительно быстро?".
Если бы вы сумели это обосновать ( а именно найти такую среду где это быстрее чем другие варианты) - прокатило бы.