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

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

PD>>1.Не сотвори себе кумира!

Д>мы ведь говорили про принцип KISS? вот у меня есть предположение, что люди, которые стояли у истоков Юникс, знают намного больше нас с тобой о его точном значении

Не понял. Или ты имеешь в виду, что я неправильно расшифровал аббревиатуру ?



Д>мы ведь говорим о программах, а не о машинах?
Д>а вот как раз они глохнут. и "взрываются". причем регулярно

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

Д>поэтому давайте сделаем сначала то, что будет нормально ездить и возить грузы. Пусть и не очень быстро, зато с гарантированной доставкой из точки А в точку Б. Причем в целом и непритронутом виде.

Нет, не пойдет. Потому что если с меня за эту поездку на самоновейшем самолете возьмут из Омска в Москву $1000, я предпочту обычный российский поезд, который довезет меня за $100, хотя, возможно, слегка опоздает. Кстати, и риск аварии там не больше, чем у самоновейшего самолета.

А программ без ошибок — не бывает. Вспомни

"Программа, свободная от ошибок, есть абстрактное теоретическое понятие".


Д>многие так думали. пока жареный петух в одно место не клюнул

Ну несерьезно это. Есть страна, для которой я это делал. Есть у них в стране некая информация (извини, но деталей рассказывать не буду). Эта информация там появилпась, когда еще никаких компьютеров на свете не было, а может, и автомобилей не было. И вот я эту информацию в некий буфер заношу. И то, что она никак не может быть больше, чем 500 символов — гарантия в 101%. Никогда не может, ну так же, как имя русское не может быть длиной в 500 символов. А времени считать эту длину абсолютно нет, потому как на все про все мне дано 100 мсек. И в этих условиях ты все же будешь утверждать, что buffer overrun возможен ?


Д>разница в том, что этот код не вызовет порчу стека. а sprintf — вызовет
Д>улавливаешь разницу?

Нет, не улавливаю. все равно это кончится неверным поведением программы и в конце концов крахом. Причем скорее всего не здесь, а где-то еще. Так что разницы я не улавливаю. Или ты хочешь сказать, что buffer overrun — это намного хуже, чем integer overflow ? По мне, один черт — все равно дальше ничего хорошего не будет.

На тебе, пожалуйста

int nScreenArea = nScreenWidth * nScreenHeight;
int nSquareLength = sqrt(nScreenArea); // а какого бы размера был квадратный дисплей с таким же числом пикселей ?

и получи sqrt domain error (не помню, как он сейчас называется правильно) — корень из отрицательного числа.

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

А это от ситуации зависит. В том проекте, в котором я участвовал, мне все было разрешено, кроме одного — низкой скорости работы. Занял бы на диске лишний Гбайт — простили бы. ОП использовал бы в 2 раза больше, чем надо — тоже простили бы. А вот уложиться я должен был в 100 мсек. Кровь из носу. Потому что если 200 мсек займет — это кончится просто тем, что данный образец будет снят с обработки по нехватке времени, а тем самым число необработанных образцов увеличится. А обрабатывается таких образцов в день примерно 30,000 только на одной машине, и на каждый образец дается не более 3 сек. И за это время к моему ПО делается 10-15 запросов плюс, естественно, то время, которое нужно на оставшуюся часть, а оно есть примерно 60% общего времени. А машин примерно 1000. Борьба шла за каждый процент. И мне все прощалось, только бы быстрее. И сделал я им вместо 100 мсек 20-30 мсек, и были они в полном восторге

А лишних Гбайтов я , кстати, не использовал. И лишней ОП — тоже. Ну разве что самую малость — буфер там был один с запасом в 64 Кбайта