Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, Ytz, Вы писали:

КД>А за рекурсию — вообще "на кол"
в си -- да. руби же хранит bignum в куче и потому разница между рекурсивным вариантом и не рекурсивным уже не столь существенна.

КД>PS. Отсутствие const у n тоже "не айс"
так оно ж не указатель. зачем ему const?!

Здравствуйте, мыщъх, Вы писали:

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

В 70% случаях когда такое выясняется (а комментария в коде нет) за фичи таки надо бить.

Здравствуйте, 24, Вы писали:

24>Здравствуйте, мыщъх, Вы писали:

М>>конструкция err = (a > b && foo(a, b)) || (a < b && foo(b, a)) || (a == b && bar(a))
24>Код, написанный с трудом, должен читаться с трудом
хотите сказать, что
if (a > b)
{
err = foo(a, b);
}
else
{
if (a == b)
{
err = bar(a);
}
else
{
err — foo(b, a);
}
}

читается лучше?!

или вот еще вариант.
if (a == b)
err = bar(a);
else
err = foo(MAX(a,b), MIN(a,b));

в принципе, вариант с MIX/MAX лучше тем, что он _читается_, согласен.

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Здравствуйте, мыщъх, Вы писали:

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

MP>В 70% случаях когда такое выясняется (а комментария в коде нет) за фичи таки надо бить.
извините, а комментировать конструкции типа a = b[c]; тоже нужно пояснять (взять элемент по индексу c от массива b)?! это же в любой книжке для чайников написано, что a = b[c] равносильно a = c[b], равносильно a = *(b + c), равносильно a = *(c + b) равносильно a = (b + c)[0], равносильно a = 0[b + c];

это как бы базовые основы при работе с указателями и массивами. я вообще-то редко использую квадратные скобки, мне как-то ближе *(array + idx). надеюсь, хоть это комментировать не надо?!

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, 24, Вы писали:

24>>Здравствуйте, мыщъх, Вы писали:

М>>>конструкция err = (a > b && foo(a, b)) || (a < b && foo(b, a)) || (a == b && bar(a))
24>>Код, написанный с трудом, должен читаться с трудом
М>хотите сказать, что
М>if (a > b)
М>{
М>err = foo(a, b);
М>}
М>else
М>{
М>if (a == b)
М>{
М>err = bar(a);
М>}
М>else
М>{
М>err — foo(b, a);
М>}
М>}

М>читается лучше?!

М>или вот еще вариант.
М>if (a == b)
М>err = bar(a);
М>else
М>err = foo(MAX(a,b), MIN(a,b));

М>в принципе, вариант с MIX/MAX лучше тем, что он _читается_, согласен.

Та я ж просто пошутил

Я обычно пишу открывающую скобку в той же строчке, и пачку else if тоже вместе, как-то так:

err = NO_ERR;

if      (a > b) { err = foo(a, b); }
else if (a < b) { err = foo(b, a); }
else            { err = bar(a);    }

Хотя сразу я и упустил из виду, что в if-else-if нужно отдельно объявлять err, а в одну строчку оно входит. Но если в той строчке заменить a, b, foo и bar на что-то более реалистичное, то она уже будет или очень длинной, или не одной строчкой.

Здравствуйте, 24, Вы писали:

24>Здравствуйте, мыщъх, Вы писали:

24>Я обычно пишу открывающую скобку в той же строчке, и пачку else if тоже вместе, как-то так:
24>

24>err = NO_ERR;

24>if      (a > b) { err = foo(a, b); }
24>else if (a < b) { err = foo(b, a); }
24>else            { err = bar(a);    }
24>

24>Хотя сразу я и упустил из виду, что в if-else-if нужно отдельно объявлять err, а в одну строчку оно входит. Но если в той строчке заменить a, b, foo и bar на что-то более реалистичное, то она уже будет или очень длинной, или не одной строчкой.

эээ... нет... т.к. if/else/if/else покрывают весь спектр вариантов, то err мусора не окажется, но компилятор скорее всего начнет ругаться. кстати, у вас ошибка. правильнее писать err = ERROR. т.к. если ни foo, ни bar не были вызваны -- тут какой-то косяк.

Здравствуйте, мыщъх, Вы писали:

М>правильнее писать err = ERROR. т.к. если ни foo, ни bar не были вызваны -- тут какой-то косяк.

Как в данном случае может не вызваться ни одна из них? А вцелом соглашусь, что если err рассматривать не как показатель ошибки в отдельных функциях, а как общий показатель правильности участка кода, то да, лучше инициализировать как ошибку.

Здравствуйте, 24, Вы писали:

24>Здравствуйте, мыщъх, Вы писали:

М>>правильнее писать err = ERROR. т.к. если ни foo, ни bar не были вызваны -- тут какой-то косяк.

24>Как в данном случае может не вызваться ни одна из них? А вцелом соглашусь, что если err рассматривать не как показатель ошибки в отдельных функциях, а как общий показатель правильности участка кода, то да, лучше инициализировать как ошибку.

Хотя я редко использую коды возврата, и если использую, то по одному, так что вопрос, чем инициализировать, не стоит:

if (!doSomething()) {
    // shit happened
}

Здравствуйте, 24, Вы писали:

24>Здравствуйте, мыщъх, Вы писали:

М>>правильнее писать err = ERROR. т.к. если ни foo, ни bar не были вызваны -- тут какой-то косяк.
24>Как в данном случае может не вызваться ни одна из них?
я же говорю -- косяк. ошибка в коде. сбой процессора. баг в компиляторе. модификация кода, ведущая к развалу логики...

> А вцелом соглашусь, что если err рассматривать не как показатель ошибки в отдельных функциях,
> а как общий показатель правильности участка кода, то да, лучше инициализировать как ошибку.
и тогда лучше завести специальное значение ERROR_IN_DNA, чтобы отличать его от ситуации возврата ошибки из функции.

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

Здравствуйте, 24, Вы писали:

24>Здравствуйте, 24, Вы писали:

24>>Здравствуйте, мыщъх, Вы писали:

М>>>правильнее писать err = ERROR. т.к. если ни foo, ни bar не были вызваны -- тут какой-то косяк.

24>>Как в данном случае может не вызваться ни одна из них? А вцелом соглашусь, что если err рассматривать не как показатель ошибки в отдельных функциях, а как общий показатель правильности участка кода, то да, лучше инициализировать как ошибку.

24>Хотя я редко использую коды возврата, и если использую, то по одному, так что вопрос, чем инициализировать, не стоит:
у меня обычно за error отвечает 0 когда возвращается указатель и -1 когда возвращается индекс. или, учитывая, что -1 не является валидным указателем на реальных платформах, -1 это ошибка, 0 — ошибки нет, но искомая строка не найдена или типа того, иначе -- указатель на то, что мы искали.

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

а чтобы отлавливать ситуации когда программист забил болт на проверку ошибок, то возврат указателя на указатель -- это просто магическое средство. т.е. если программист сделает pp = foo(a,b); c = *pp; то при возникновении ошибки foo вернет не указатель на ноль, а просто ноль и программа без проверки ошибок тут же грохнется.

Здравствуйте, мыщъх, Вы писали:


М>>>программисты забивали на мой make болт, копипастили мой сорец себе и говорили, что у меня ошибка и все тут неправильно и оно даже не компилируется.
Z_>>Дык они че, тупо через cl компилили?)
М>под никсами? cl ?! там вообще-то gcc.
А, простите, от гцц с линухами вообще-то стараюсь подальше держаться) Так что могу тормознуть и ляпнуть)

М>и "затмение" в качестве среды разработки.
Можно просто эклипс) Или вы нарочно делаете ударение на смысл этого слова?)

М>засунули два моих файла (хотя на самом деле там их не два, а больше, но это мелочи) в свой проект -- .c и .h, "затмение" создало .o файл для .c и правильно его подключило, но вот зависимость по zlib так и осталась болтаться.
Кросавхчеги, че.

Z>> Это не программисты, это... другие специалисты.
М>а классическая шутка y = 3["0123456"] (подчеркиваю _классическая_) закончилась дракой, поскольку, сначала они утверждали, что это баг компилятора, а после того как выяснили, что это не баг, а фича, они меня за такие фичи бить начали. а конструкция err = (a > b && foo(a, b)) || (a < b && foo(b, a)) || (a == b && bar(a)) вообще переросла в ледовое побоище и они ее переписали на if else if else.
Вы знаете, я и сам стараюсь писать попроще, но тому есть две причины — во-первых сам не эксперт, во-вторых разобраться в простой конструкции на экран проще, чем в мозговороте в одну строчку. Но чтобы морду за это бить... Я бы помалкивал например, и учился бы, благо есть попутный повод поднять свой уровень. С другой стороны, для нормальной поддерживаемости кода его на самом деле нужно писать попроще. Об этом можно договариваться, идти на компромиссы. Но пинать человека за то, что он знает больше тебя... Какие-то непуганые идиоты у вас там работают.

Здравствуйте, мыщъх, Вы писали:

КД>>PS. Отсутствие const у n тоже "не айс"
М>так оно ж не указатель. зачем ему const?!

Думай лучше о бабах

PS. Это C++ные заморочки.

Ни разу в жизни не пользовался эквивалентностью a[с] и с[a], хотя знаком с этим как с очередным сишным курьезом. Допускаю, что разработчик имеет право не знать такой востребованной и частоупотребляемой "фичи" языка, тем более что она не дает ничего нового, а является редко используемой формой записи.
Оператор запятая, думаю, также не знаком многим разработчикам, уже не помню когда я его в последний раз видел в сорцах, вот и нефиг его использовать, если можно обойтись.

23.03.2011 22:33, мыщъх пишет:

> c)[0], равносильно a = 0[b + c];
>
> это как бы базовые основы при работе с указателями и массивами. я
> вообще-то редко использую квадратные скобки, мне как-то ближе *(array +
> idx). надеюсь, хоть это комментировать не надо?!
Не надо. Но надо быть готовым к тому, что скоро на замену термину
"индусский код" придет термин "русский код".
А за такое в коде я бы бил больно и ногами.

Здравствуйте, мыщъх, Вы писали:

М>вот руби кидает исключение при ошибке открытия файла и мне непонятно почему. это же совершенно нормальная ситуация. хотели открыть файл, а нас обломали. у программиста есть все возможности обработать эту ситуацию, проверив валидность дескриптора. зачем же сразу кидаться исключениями?
В случае открытия файла это сделано, как мне кажется, скорее для единообразия (т.к. исключения используются везде, и код возврата только для одной функции делать нет смысла), а не потому, что так лучше. Хотя, чем проще ошибку проигнорировать, тем выше шансы, что она таки будет проигнорирована. Чтоб проигнорировать код возврата — не нужно делать ничего, а чтоб проигнорировать исключение — это нужно явно писать. Необработанное исключение сразу обвалит программу (и будет понятно, где она обломилась), а с необработанным кодом ошибки выполнение молча продолжится, и ошибка, которая произошла в одном месте, вызовет странные эффекты позже в другом месте, и надо ещё разбираться, что оно работает здесь неправильно из-за того, что где-то раньше была ошибка. Но в простых случаях, типа возврата указателя или индекса, я тоже предпочитаю возвращать NULL или -1 соответственно, как признак отсутствия или невозможности получения чего-либо.

М>а вот если инвалидный дескриптор передан в read/write, то здесь, согласен, исключение выглядит намного логичнее возврата ошибки, т.к. раз инвалидный дескриптор попал в read, то, очевидно, программист уже накосячил и продолжать выполнение программы -- бессмысленно.
Можно вернуть код ошибки ERR_INVALID_DESCRIPTOR, тоже можно обработать, как и в случае с обломом открытия файла.

Здравствуйте, 24, Вы писали:

24>Здравствуйте, мыщъх, Вы писали:

24>В случае открытия файла это сделано, как мне кажется, скорее для единообразия
24>(т.к. исключения используются везде, и код возврата только для одной функции
24>делать нет смысла), а не потому, что так лучше.
питон исключение не кидает. и дает мне возможность проверить открытие файла самому. и исключение выпрыгивает только при чтении.

> Хотя, чем проще ошибку проигнорировать, тем выше шансы, что она таки будет проигнорирована.
исключение тоже можно игнорировать. сейчас вот юзаю утилиту коллеги, которая коннектиться к localhost SQL-серверу и работает с ним. заменив localhost на IP я получил возможность работать и с удаленным сервером, но вот засада -- исключения ловятся только на самом верхнем уровне и потому когда к удаленному хосту не приконнектишься или когда какой-то косяк с авторизацией или еще что-то, то все это завершается однообразно и мне совершенно непонятно почему меня обломали? так что исключения тут ничем не помогают, ибо нет обработки ошибок. даешь запрос, а возвращается пустая строка. это значит: ни фига не найдено || соединение установить не удалось || пароль неправильный. с учетом нестабильности тырнета такая неоднозначность становится катострофической.

> Чтоб проигнорировать код возврата — не нужно делать ничего,
> а чтоб проигнорировать исключение — это нужно явно писать.
да ладно. устанавливаем один обработчик исключений и на все исключения реагируем однообразно -- вполне типичная практика.

> Необработанное исключение сразу обвалит программу (и будет понятно, где она обломилась),
> а с необработанным кодом ошибки выполнение молча продолжится,
исключение выпрыгнет, но чуть позже. скажем, если malloc вернет ноль (памяти нету), то исключение будет при обращении к этому указателю (правда, 100% гарантии в этом у нас нет, но есть 99%). главное, не возвращать мусор. например, если read() на попытку чтения по невалидному дескриптору вернет "", то это не сильно печально и логика программы не пострадает даже без явного контроля ошибок. в случае текстового редактора при ошибке открытия файла редактор покажет пустую страницу. а вот необработанное исключение обрушит всю несохраненную работу. я думаю, что первое намного лучше второго.

вот тут сейчас заюзал одну библиотеку для логгирования, которая при ошибке иницилизации возвращает ошибку и тогда у меня вместо логгирования идет вывод на консоль (ну а что еще делать?!). вот только... иногда библиотека еще и исключение кидает (например, когда файл лога заблокирован другим приложеним) и этот факт в документации _не_ упоминается. и мое приложение неожиданно получает исключение, к которому оно не готово. причем у меня все работает, а у юзера -- нет. кто ж знал, что он собака открывает файл лога вордом, ворд блокирует файл, юзер запускает приложение. приложение рушится. а я никак не могу воспроизвести у себя эту ситуацию, поскольку всегда смотрю логи фаром.

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

М>>а вот если инвалидный дескриптор передан в read/write, то здесь, согласен, исключение выглядит намного логичнее возврата ошибки, т.к. раз инвалидный дескриптор попал в read, то, очевидно, программист уже накосячил и продолжать выполнение программы -- бессмысленно.
24>Можно вернуть код ошибки ERR_INVALID_DESCRIPTOR, тоже можно обработать, как и в случае с обломом открытия файла.
разница в том, что на момент открытия файла программист еще не успел накосячить, а на момент чтения стало ясно, что он забил на обработку ошибок болт.

Здравствуйте, мыщъх, Вы писали:

М>питон исключение не кидает. и дает мне возможность проверить открытие файла самому. и исключение выпрыгивает только при чтении.
Хмм, в какой версии?
В моей 2.6 прямо на open кидает, в справках к 2.7/3 написано, что тоже кидает.

Здравствуйте, мыщъх, Вы писали:

М>исключение тоже можно игнорировать.
Сознательно отстрелить себе ногу С++ не запрещает, исключения помогают только от случайных ошибок, а не от целенаправленного их игнора.

М>сейчас вот юзаю утилиту коллеги, которая коннектиться к localhost SQL-серверу и работает с ним. заменив localhost на IP я получил возможность работать и с удаленным сервером, но вот засада -- исключения ловятся только на самом верхнем уровне и потому когда к удаленному хосту не приконнектишься или когда какой-то косяк с авторизацией или еще что-то, то все это завершается однообразно и мне совершенно непонятно почему меня обломали? так что исключения тут ничем не помогают, ибо нет обработки ошибок. даешь запрос, а возвращается пустая строка. это значит: ни фига не найдено || соединение установить не удалось || пароль неправильный. с учетом нестабильности тырнета такая неоднозначность становится катострофической.
Если возвращается пустая строка, а не вылетает исключение, то его уже перехватили раньше, и сознательно не обрабатыавают нормально, а просто возвращают пустую строку в случае любой ошибки. Исключения, здесь, по-моему, ни при чём, т.к. при использовании этой утилиты неизвестно (если абстрагироваться, и не знать, как эта утилита написана), почему вернули пустую строку. Вполне могло оказаться, что внутри используются коды возврата, и пустая строка возвращается при любом из них. Другое дело, если бы вместо пустой строки вылетало исключение, соответсвующее тому, какая ошибка произошла. И если специально не писать catch(...), что показывает — мне пофик, какая это ошибка, а обрабатывать каждую как надо, то появление нового вида ошибок проигнорировать не получится.

М>да ладно. устанавливаем один обработчик исключений и на все исключения реагируем однообразно -- вполне типичная практика.
Печально, если это действительно типичная практика. Но даже в этом случае, ошибки хоть как-то обрабатываются (хоть сообщение в лог "тут произошла какая-то ошибка"), а код возврата можно тупо забыть проверить, особенно если добавился ещё один.

М>например, если read() на попытку чтения по невалидному дескриптору вернет "", то это не сильно печально и логика программы не пострадает даже без явного контроля ошибок. в случае текстового редактора при ошибке открытия файла редактор покажет пустую страницу. а вот необработанное исключение обрушит всю несохраненную работу. я думаю, что первое намного лучше второго.
Пострадает психика пользователя этой программы, если он вместо некоторого файла будет постоянно видеть пустой лист. А так хоть будет знать, что явно баг в программе, если она упала. (А какая несохранённая работа при открытии файла?)

М>вот тут сейчас заюзал одну библиотеку для логгирования, которая при ошибке иницилизации возвращает ошибку и тогда у меня вместо логгирования идет вывод на консоль (ну а что еще делать?!). вот только... иногда библиотека еще и исключение кидает (например, когда файл лога заблокирован другим приложеним) и этот факт в документации _не_ упоминается. и мое приложение неожиданно получает исключение, к которому оно не готово. причем у меня все работает, а у юзера -- нет. кто ж знал, что он собака открывает файл лога вордом, ворд блокирует файл, юзер запускает приложение. приложение рушится. а я никак не могу воспроизвести у себя эту ситуацию, поскольку всегда смотрю логи фаром.
Так пользователь увидел, что упала — написал багрепорт. Если бы вместо исключения был какой-то другой код ошибки (который в документации не упоминался бы, как и исключение), стало бы проще? Ведь проверки на тот код ощибки тоже бы не было. И логи могли бы молча не дописаться в заблокированный файл, и пользователь бы об этом не подозревал. Имхо, лучше пусть упадёт, и пользователь будет точно знать, что ошибка, чем он будет думать, что всё нормально, но лог будет неполный.

>> и ошибка, которая произошла в одном месте, вызовет странные эффекты позже в другом месте,
>> и надо ещё разбираться, что оно работает здесь неправильно из-за того, что где-то раньше была ошибка
М>исключения от таких ситуаций не спасают. вот была у меня как-то ошибка, когда при определенных обстоятельствах функция возвращала строку без нуля, но все-таки ноль был чисто потому, что повезло. и падение происходило очччень далеко от места вызова. причем каждый раз в разном месте.
Для того, чтоб выбросить исключение или вернуть ошибку, нужно сначала определить, что что-то пошло не так. В случае с отсутствием нуля, ошибочная ситуация очевидно не распознавалась (иначе бы дописался ноль, и никаких ошибок). Это просто баг, который ни к исключениям, ни к кодам ощибок отношения не имеет.

М>>>а вот если инвалидный дескриптор передан в read/write, то здесь, согласен, исключение выглядит намного логичнее возврата ошибки, т.к. раз инвалидный дескриптор попал в read, то, очевидно, программист уже накосячил и продолжать выполнение программы -- бессмысленно.
24>>Можно вернуть код ошибки ERR_INVALID_DESCRIPTOR, тоже можно обработать, как и в случае с обломом открытия файла.
М>разница в том, что на момент открытия файла программист еще не успел накосячить, а на момент чтения стало ясно, что он забил на обработку ошибок болт.
Какая разница, каким образом здесь функция read/write сообщит о невалидности переданного дескриптора — исключением, или кодом ошибки? Хотя в контексте их сравнения разница есть — если вылетит исключение, и не обработаем — то упадёт. А если вернёт ошибку, и не проверим её, то просто не запишется в файл, и будем думать, что всё ок, а потом прийдется только догадываться, почему файл пустой.

Всем спасибо за советы!

Здравствуйте, stdcout, Вы писали:

S>... переходить к .NET.

.NET — это тема =)