Мегасрач у belnetmon

[psilogic]

На 500+ комментариев:

http://belnetmon.livejournal.com/1024560.html

Для непрограммистов объясняю суть: при собеседовании на работу программиста человеку предлагается пройти тест: написать реальную простенькую программу и посмотреть, получится ли у него.

Казалось бы, что в этом требовании такого странного? Реакция, однако, забавная. В тему набежало некоторое количество мутных личностей, которые стали писать о том, что предлагаемые задачи недостаточно простые или недостаточно стандартные.

Мне кажется, что суть проблемы такова: некоторые мои коллеги учатся не столько программировать, сколько красиво гнуть пальцы. Человек помнит огромное количество всяких продуктов, языков и систем. Но знания кандидата по каждому пункту укладываются в 1-2 абзаца. Это значит, что на собеседовании он легко может поддержать беседу о данной системе, но вот написать что-то реальное - фиг.

Я называю этот типаж "эрудитом".

Если попросить эрудита написать программу типа описанной в тесте, то он будет
- Два дня читать документацию
- Два дня гуглить
- Два дня шариться по форумам
- К началу следующей недели он найдет-таки на каком-то форуме подходящую программу, скопипастит ее, и она заработает.

При этом эрудит будет страшно горд теми фактами, что:
1. Он не изобрел велосипед (ибо изобретать велосипед неправославно).
2. Он использовал проверенный, работающий код - ибо все, что опубликовано в инете, в понимании эрудита работает идеально. В отличие от сделанного руками (см п.1)
3. Он сэкономил работодателю кучу бабок, так как см. пункт 1.

Особо продвинутый эрудит способен обернуть найденную копипасту в "паттерн". Как правило, результат от этого потеряет в качестве. Но эрудит будет убежден, что результат, напротив, приобретет дополнительные магические свойства типа "расширяемость +5". Просто потому как в книжках про "паттерны" много говорится про такие вещи. Поэтому всякий паттерн - это сразу большой плюс, а любой код, в котором эрудит сходу не увидит один из 20-30 знакомых паттернов, есть неправославный велосипед и должен вместе с афтаром гореть в аду.

Например, преобразование int в строку - это не паттерн...

Comments

Re: int в строку

[psilogic.livejournal.com]

хотя бы так :)

Re: int в строку

[kelavrik-0.livejournal.com]

Вообще задал ты тему. Сейчас читаю:
#define mul(x) x*x
printf("%d", mul(5+5));
Я долго думал:
1) Нафига такое определять через макрос? Почему не через inline?
2) Оборачивается ли х скобками в макросе
3) Зависит ли это от компилятора?

Я то просто не стал бы писать то, что можно понять неоднозначно.

Re: int в строку

[psilogic.livejournal.com]

1) потому что это задачка
2) если сам не обернешь, то не оборачивается - в том-то и суть
3) не зависит

Re: int в строку

[kelavrik-0.livejournal.com]

Ага, раньше всегда писал типа:
void fun(char *name)
{
FILE *out;
out=fopen(name, "w");
}
fun("aaa.dat");

На новом компиляторе ругаться стал, мол надо не char, а const char.
То есть некоторые вещи от компилятора зависят. Могут и дефайн обернуть в скобки. Но главное, использование макросов для подобных задач вообще плохой стиль. Я бы указал, что возможны варианты и указал их.

Re: int в строку

[no1u1w1w6c]

>Могут и дефайн обернуть в скобки
такой компилятор надо аккуратно собрать в архив, а архив уничтожить.

кстати, ругань компиляторов по поводу const считаю совершенно идиотской: по-сути, компилятор заставляет меня делать то, что может и сам. у любого приличного компилятора хватает мозгов понять, что параметр не меняется — ну и делай себе код, чего материться-то? но нет, какой-то мудак посчитал, что это, де, понизит качество кода. я с нетерпением жду, когда же аффтары компиляторов наконец додумаются выкинуть из них кодогенераторы, а то что-то людишки совсем разбаловались. пусть переводят высокоуровневый код в машинный руками, а задача компилятора будет — проверить перевод и выдать 9e+3 варнингов, но ни в коем случае не поправлять ничего.

[psilogic.livejournal.com]

Декларация функции - это что-то типа декларации о намерениях. Когда пишешь char* name вместо const char* name, то тем самым декларируешь намерение этот самый 'name' изменять. Если не сейчас, то когда-нибудь. А на вход суется то,что изменять нельзя. Отсюда и ругань.

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

Сам же на стенку от тормозов и полезешь :)

[no1u1w1w6c]

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

хотя, конечно, тонкая настройка варнингов решает, да и я сам везде консты леплю, факт. привычка осталось ещё со времён очень тупых компиляторов, которые часто генерили лучший код, если const зафигачить.

но всё это, опять же, не отменяет того, что у компилятора должен быть нормальный lint-режим, в котором он не идиотскими варнингами будет верещать, а нежно советовать: «вот тут const поставь, чувак. а вот тут у тебя простыня на 25 экранов с охуенным LOC, сделай с ней что-нибудь!» и ты пы.

[psilogic.livejournal.com]

[ всё равно они нужны ровно для того, чтобы быстро сделать реализацию Схемы, и остальную часть проекта писать уже на нормальном языке. ]

гы гы гы :))

[no1u1w1w6c]

да. я бы давно совсем на Схему перешёл (та же Ypsilon, например, офигенно крута), но не все заказчики проникаются илитарным духом, увы. что не мешает мне аккуратно встраивать в софт всякие Схемы. сначала — типа для чтения конфигов. потом — чуть-чуть скриптов («это для вашего же удобства!»). а там, глядишь, и половина софтины уже на Схеме. и никто уже никогда не поймёт, как она работает — потому я незаменим. %-)

[gaussrifle.livejournal.com]

Когда пишешь char* name вместо const char* name, то тем самым декларируешь намерение этот самый 'name' изменять. Если не сейчас, то когда-нибудь.

а если у меня не прокатывает, я посылаю компиллятор нахуй и делаю так

void fun(const int * k)
{
int * t=NULL;
__asm
{
push k
pop t
}
t[0]=30;
}

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

[psilogic.livejournal.com]

зачем такие навороты??

void fun(const int * k)
{
int* t= (int*)k;
t[0]=30;
}

и фсё

[psilogic.livejournal.com]

по-хорошему такую функцию не надо декларировать с const, но если уж сильно приспичило, ассемблер ни к чему

Re: int в строку

[kelavrik-0.livejournal.com]

Может вы и правы. Это вечный источник ошибок.

Re: int в строку

[no1u1w1w6c]

тут, на самом деле, тонкая грань. с одной стороны — лишний мат раздражает. с другой — помогает менее опытным дисциплинироваться.

Re: int в строку

[gaussrifle.livejournal.com]

см http://psilogic.livejournal.com/357926.html?thread=7330598#t7330598

Re: int в строку

[psilogic.livejournal.com]

Вообще говоря, это старинная классическая задачка, которая появилась еще в те времена, когда никаких inline и, тем более, template еще не было. По нынешним временам лучше всего template + inline:
template <class T> inline T mul(T v) { return v * v; }
(лучше в первую очередь тем, что v не будет вычисляться дважды).

Re: int в строку

[kelavrik-0.livejournal.com]

Аха, если T это двумерная матрица 10³*10³. Столько памяти забьётся при копировании...

Re: int в строку

[psilogic.livejournal.com]

Я считаю, что для матриц и "тяжелых" объектов лучше вообще таких функций не делать. Даже, если параметр сделать ссылкой, придется копировать при возврате return. Для матриц надо что-то типа:

... void mul(const T& in, T &out) ...

Re: int в строку

[kelavrik-0.livejournal.com]

Ну так я ровно о том: передавать объекты или ссылки на объекты. Именно поэтому, imho, темплейтов вообще стоит избегать.

Re: int в строку

[psilogic.livejournal.com]

Зачем избегать? Представь себе, что у тебя куча возведений в куб типа такого:

(x + 3)*(x + 3)*(x + 3) + (y*y*y + z)*(y*y*y +z)*(y*y*y +z) + ...

согласись, так:

kub(x + 3) + kub(y*y*y + z) + ...

- будет выгоднее, т.к. не надо заводить временных переменных, которые сразу же и выбросишь, и не надо трижды вычислять y*y*y + z.

А темплейт тут нужен, чтобы не писать версии kub отдельно для int, double, float...

Re: int в строку

[kelavrik-0.livejournal.com]

Ну начнём плясать от печки. Накуя вообще float? С ним программа работает существенно медленнее. Посему остаются int & double. Ну напишу пару раз, это не проблема. А если надо расширить функцию для комплексных чисел, то могут возникнуть ньюансы. Нет, при возведение в куб нет проблем, а вот корень третьей степени, это уже ньюанс. Да, корень третьей степени не имеет смысла для int. То есть темплейты охватывают очень мало реальных задач (имхо).

Re: int в строку

[psilogic.livejournal.com]

[ Накуя вообще float? С ним программа работает существенно медленнее. ]

Пример - моя (и не только моя) программа обработки звука. 16 бит достаточно для воспроизведения в отличном качестве, но при редактировании возникает эффект накопления погрешностей. Поэтому надо 32 бита. А 64 (double) бита - уже жирно, поскольку звуковые файлы и без того огромны (пока их не сжали).

Темплейты охватывают до хрена реальных задач. Пример из той же оперы. Некий модуль программы меняет pitch (высоту) звукозаписи. Хочется, чтобы он мог работать и с 32-битным звуком, ибо удобен, и с 16-битным, ибо стандарт. Алгоритм непростой (учитывая буферизацию и интерполяцию). И накуя, спрашиваетяс, я буду писать три версии этого алгоритма (под short, int, float)? Естественно, я и не пишу, у меня это оформлено как template.

Re: int в строку

[kelavrik-0.livejournal.com]

Понятно. Я бы считал всё с максимальной точностью, а сокращал бы при сохранении.

[psilogic.livejournal.com]

Я и не считаю во float, но значительную часть алгоритма составляют чтения/записи в разных точках звуковой дорожки, которые перемешаны с вычислениями. Соответственно пришлось бы делать много-много копипасты и допускать кучу ошибок, связанных с копипастой. Можно перегонять каждый раз в double и обратно, но это - дополнительные накладные расходы, которые не оправдать ничем, кроме разве что нелюбви к template-ам :)

[kelavrik-0.livejournal.com]

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