| |
| 2.3, grislock (ok), 00:29, 15/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
как и для любого другого средства разработки веб-приложений, стандарт простой:
не верь данным приходящим снаружи.
Для этого думать иногда приходится, что зачастую делать php-програмеры не любят, но это все таки не вина php, как мне кажется.
| | |
| |
| 3.5, aleoparin (ok), 01:53, 15/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
ну не только это, еще хотя-бы деление на нуль тоже проверить не помешает .. ;)
| | |
|
|
| |
| 2.8, ДяДя (?), 11:07, 15/03/2008 [^] [^^] [^^^] [ответить]
| +/– | |
+1
Похоже на попытку повесить броню на деревянный самолёт, когда другие у же давно поняли, что самолёты проще из металла строить.
| | |
| |
| 3.10, Vvv (?), 13:13, 15/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Esli ne secret, chto vi imeete v vidu pod "derevyanniy samolyot" i chto togda po vashemu "metal"?
| | |
| 3.12, earl (?), 14:57, 15/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Ага, когда то мой товарищ си-плюс-плюсник был в замешательстве, читая книжку какогото корифея C++, в ней в одном разделе писалось, что его нельзя ипользовать для написания высоконадежных программ, особенно связаных с критическими вещами и безопасностью жизни, приводились примеры почему.
В качестве альтернатив упоминалась АДА, и еще что то, непомню
| | |
|
| 2.17, TyLLIKAH (?), 16:35, 16/03/2008 [^] [^^] [^^^] [ответить]
| +/– | |
C - это инструмент, которым можно либо легко и удобно работать, а можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все должны есть ложками, вилками можно выколоть себе глаз ненароком. Прокатит такое в реальной жизни ? Например: у мебели не должно быть острых углов, а все стены должны быть оббиты мягким материалом - добро пожаловать в дурдом. В С программисту предоставлена свобода: не хочешь использовать множественное наследование - не используй, не хочешь использовать голые указатели - не используй.
У нас один "корифей" преподавал язык Ада в универе таким образом: говорил "множественное наследование - это ужас, мучения и смерть. В Аде такой бяки нет!" и тут же рисовал пример на Аде: подключение кучи пакетов, и написание альясов к ним. Разобрать потом, что откуда он дёргает было невозможно. Реально адский язык.
По поводу мышей: сначала мне говорили: пролог - язык будущего, С - мёртв. Потом мне говорили Паскаль - язык настоящего, а С мёртв. Потом мне говорили Java - язык завтрашнего дня, С - мёртв окончательно, наконец-то изобрели СHash - теперь С точно помер... А С всё живёт и живёт. И Борланд ворует в свой Delphi сишные фишки, и cvsup на С переписали наконец-то (с ультрабезопасной модулы, придуманной гениальным Виртом), и стандарты вот разные принимают. Странно как-то для мёртвого языка. Нет? С\С++ - это идеальный компромисс между быстродействием и надёжностью, всё остальное академические поделки, представляющие лишь научный интерес.
| | |
| |
| 3.25, f00l (ok), 10:19, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >С\С++ - это идеальный компромисс между быстродействием и надёжностью,
>всё остальное академические поделки, представляющие лишь научный интерес.
полностью поддерживаю !!!
| | |
| 3.32, muxas (??), 16:58, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>C - это инструмент, которым можно либо легко и удобно работать, а
>можно отрезать себе руку. Всё зависит от вашей квалификации. Например: все
>должны есть ложками, вилками можно выколоть себе глаз ненароком.
Однако, согласитесь, кусок мяса есть вилкой удобнее, чем ложкой. А суп вилкой одолеть будет еще сложнее. Так что не забудем, для какой задачи мы используем язык.
>всё остальное академические поделки, представляющие лишь научный интерес.
зачастую далеко не академические, иногда не поделки, и если до сих пор существуют, значит к ним есть интерес в широких массах... ;-)
| | |
|
|
| |
| 2.16, coder (?), 14:54, 16/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
статья по линку очень смешная
это еще автор всего опенсоурс нерасматривал....там еще хуже)))))
но речь не о том
все что рассматривал автор имет смысл ТОЛЬКО если это разработка ведеться группой разработчиков
но если это работа двух трех девелоперов
то поверте ничего страшного в int avg(int a, int b) { return (a + b) / 2; }
я невижу
если изначально вся программа использующая это продумана
и уже изначально a и b не будут приходить такими.....
есть много примерв
где к примеров программ очень граммотно написаных
делают write(fd, element->buffer, element->length) когда
element = NULL;
НО
список из которого это читаеться никогда не будет включать таких NULL элементов
но это ньюансы
| | |
| 2.18, KBAKEP (??), 19:26, 16/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Чёт автор перемудрил. Если ему не нравится
int avg(int a, int b) { return (a + b) / 2; }
то легко можно переписать так:
int avg(int a, int b) { return 0.5*a + 0.5*b; }
Без условных переходов, переполнений и "левых" функций типа sign().
| | |
| |
| 3.19, аноним (?), 22:23, 16/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
А ничего, что функция возвращает int (целое), а возвращаемое значение вычисляется делением на 2? :) Т.е. возвр. значение должно быть числом с плавающей точкой.
| | |
| |
| 4.20, никто (??), 23:34, 16/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Тогда уж логичнее
int avg(int a, int b) { return a/2 + b/2; }
хотя умножение на 0.5 тоже нормально работает. :)
| | |
| |
| 5.21, citrus (??), 01:08, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Тогда уж логичнее
> int avg(int a, int b) { return a/2 + b/2; }
Подумайте, что вернет этот вариант avg(1,1)
| | |
| |
| 6.22, никто (??), 02:19, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Вернёт 0, но речь то о том что нужно избежать переполнение буфера, а точность возвращаемого результата зависит от поставленной задачи. Может мне и нужно чтобы функция в таком варианте параметров возвращала 0, главное чтобы не было переполнения. :)
| | |
| 6.24, аноним (?), 07:52, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> int avg(int a, int b) { return a/2 + b/2; }
>Подумайте, что вернет этот вариант avg(1,1)
1/2 + 1/2 = 1
Не знаю где тут выкопали 0 %)
| | |
| |
| 7.27, f00l (ok), 10:23, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>> int avg(int a, int b) { return a/2 + b/2; }
>>Подумайте, что вернет этот вариант avg(1,1)
>
>1/2 + 1/2 = 1
>
>Не знаю где тут выкопали 0 %)
это на бумаге 1 а в программе 0
| | |
|
|
|
|
|
| 2.23, Vital (??), 05:26, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий программирование. Если имеется вероятность переполнения, то куда правильней использовать более вместительный тип данных, например, если int - это 32 бита, то функция будет выглядеть так:
int avg(int a, int b) { return ((int64)a + (int64)b) / 2; }
Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом :)
| | |
| |
| 3.28, Keeper (??), 10:35, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Лучше сразу тип данных с плавающей запятой, тогда и округление будет точнее.
int avg( int a, int b) {
return (int) lround( ((double)a + (double)b) * 0.5);
}
| | |
| |
| 4.34, Vital (??), 18:17, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
нет не лучше, ибо совсем другие инструкции процессора и совсем другие такты
| | |
| |
| 5.35, smb (?), 21:19, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
FPU достаточно быстро работает на современных процессорах, не надо ля-ля. Ничуть не медленней АЛУ. На конвертацию да, придётся потратиться...Но я бы стал так писать, если что - ибо пара тактов в нерасчётной задаче абсолютно некритична.
| | |
| |
| 6.36, Vital (??), 21:49, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
да конечно можно кивать в сторону скорости процессоров, и писать проги в стиле "лижбы работало", но применять решения с плавающей точкой, там, где все элементарно делается целыми числами, мягко говоря не разумно.. хотя, конечно, у каждого свой взгяд на жизнь...
| | |
|
| 5.37, Keeper (??), 09:41, 18/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Согласен. Но:
1. Смотря какого процессора. На i686 преобразование int <-> double займет лишь несколько тактов.
2. В исходной задаче нигде не было сказано, что пользоваться следует только целочисленной арифметикой. ;)
| | |
|
|
| 3.29, иван (??), 12:24, 17/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
в твоем варианте результат будет неверен оно будет усечено >int avg
| | |
| 3.38, 11a (?), 02:37, 19/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >Жуткое решение предлагает автор, такое мог написать разве что школьник, только изучающий
> программирование.
Полностью не согласен!! Пустые штампы без аргументов%)
> Если имеется вероятность переполнения, то куда правильней использовать более
>вместительный тип данных,
Да, "куда правильней"??
> например, если int - это 32 бита, то
>функция будет выглядеть так:
>
>int avg(int a, int b) { return ((int64)a + (int64)b) / 2;
>}
Я считаю просто лишние операции на преобразование и вычисление для x86 например.
Так а если у нас аргументы сами уже будут avg(long long int a, long long int b) что тогда?? ;))
К тому же с переносимостью тоже не всё ясно - С99??
На том же сайте обсуждается более эффективый алгоритм.
>Однако, на ассемблере можно сделать еще элегантнее с тем же самым типом
PS. В тему!! http://www.wasm.ru/article.php?article=onebyte
| | |
|
|
| 1.30, аноним (?), 13:06, 17/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
При умножении на 0.5 происходит автоматическое приведение к типу double. Приведение к int происходит только когда уже вычислено значение выражения, так что в таком варианте avg(1,1) вернёт 1.
Имеем два преобразования int в double, три операции с плавающей точкой, и обратное преобразование double в int. В варианте из статьи имеет два вычисления знака int, один переход и две операции с int( вычисление знака тоже можно сюда отнести, так что будет всего 4 с int и один if).
| | |
|
