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

[avva]

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

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

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

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

Comments

[d-ohrenelli.livejournal.com]

А оно всегда так.
У меня есть 3 таких вопроса (рассказывать не буду), которые с точностью 99 % предсказывают результат интервью, причем годный человек отвечает на них мгновенно, а негодный трепыхается по 10 минут на каждом.

А на вопросе о разделении файла на четные и нечетные строчки валится такая дикая толпа народу, что подумать страшно.

[huzhepidarasa.livejournal.com]

А по секрету? ;)

[d-ohrenelli.livejournal.com]

Как задачи сменим - обязательно расскажу :)

[francis-drake.livejournal.com]

И мне расскажите, если не затруднит.

[huzhepidarasa.livejournal.com]

Злые, нехорошие люди, не делятся задачками :(

[d-ohrenelli.livejournal.com]

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

[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]

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