Очередной раунд баталии, кажется, завершён, оглянемся.

Действующие лица и исполнители.

safe-тусовка — некий народ, вполне оформленно излагающий safe-"парадигму".
unsafe-тусовка — явной "парадигмы" не проповедует и на фоне предыдущих выглядит форменными анархистами.

Забавно, что именно "парадигму" в её википедическом толковании safe-тусовка и исповедует. Это действительно "взгляд", причём основательно замутнённый.

...

Главное, на мой взгляд, столкновение, произошло даже не на почве safe/unsafe. Этого противоречия по сути, не было даже в помине. Во всяком случае, unsafe-тусовка даже не пыталась сказать, что, на безопасность можно начхать и, скажем, лепить буфер произвольного размера.

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

void func(int n, int v)
{
  char buffer[500];
  sprintf(buffer, "<c1>%d</c1><c2>%d</c2>", n, v);
    
  // что-то делаем с buffer
}

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

Любопытными оказались два момента, связанные с safe-правилами по отношению к языкам C/C++.

Первый: почему snprintf и прочие функции, контролирующие длину буфера (в дальнейшем — ФКДБ) a priori полагаются безопасными, тогда как sprintf и прочие подобные — нет?

Второй: почему выбор заведомо достаточного размера буфера без последующей проверки не считается safe-подходом?

Налицо двойной перекос в позиции safe-тусовки: первый — неправомерное сужение safe-методик C/C++ до ФКДБ; второй, следующий из первого — отрицание возможности использования якобы unsafe-механизмов. Никаких рациональных обоснований safe-тусовка так и не привела, вот потому я и сказал в самом начале о "взгляде", сиречь — о "парадигме". А как ещё называть сугубо иррационально обоснованные высказывания?

Первое противоречие простительно из-за того, что сходу подменили ФКДБ на некий общий safe. Я и сам время от времени сбивался из-за терминологической перекошенности.

А за второе противоречие я должен извиниться перед safe-тусовкой, поскольку сознательно не стал обращать на него внимание. Просто было интересно: догадаются или нет? Не догадались. Во всяком случае, я нигде подобного признания не прочёл. Может, ошибся. Как бы то ни было, обвинения меня и прочих оппонентов в "создании хаоса" не остановились, следовательно, safe-тусовка продолжает ассоциировать snprintf с однозначно надёжным стилем программирования.

На первый взгляд, аргументация safe-тусовки не кажется такой уж иррациональной. И правда, все упомянутые ими "может быть" могут быть и на самом деле. Только одна несуразица. Когда мы говорим о "может быть", нужно отдавать себе отчёт в том, что на самом деле быть может и чего не может в даном конкретном месте и времени. Многовато "может быть" на квадратный сантиметр, не правда ли?

Программирование и в самом деле окружено массой предрассудков, страхов, предостережений на ровном месте. В немалой степени этому способствуют разнообразные книги по поводу good practices. Авторы таких книг зачастую формулируют мысли так: "Мы изучили опыт N команд в M странах, и пришли к выводу, что strcpy — опасная вещь, потому что..." И после этого "потому что" текст может отсуствовать или может идти нечто невнятное. А из подобной литературы нередко запоминается только самое основное и краткое — вывод, но не предпосылки. И в пересказе получается так: "strcpy — плохо, потому что его использование влечёт массу неприятностей". Да и не только про strcpy такое говорят. Такие же ссылки я слышал и на высказывания Вирта про языки, и на Буча с его примерами классов и ещё на кучу других гранд-авторов компьютерной литературы.

Хотя у того же Буча целые главы посвящены тому, чтобы донести до сознания читателя: "Всё, что я сказал, имейте ввиду, но свою голову с плеч не снимайте". Почему об этом забывают? Не знаю. За всех сказать я тут ничего не могу. Могу только рассказать одну историю.

[история on]
В конце 90-х мне довелось участвовать в проекте биллинговой системы. В самой системе ничего особенного не было, даже биллинг оффлайновый. C++ под Win16 и Win32. Соответственно — ODBC, MFC, ATL. Однако, в коде периодически попадались вставки для Макинтоша...

Был тогда такой фетиш — многоплатформенность. Возможно, это были отголоски ещё недавних войн SCO Unix против Windows во имя мирового господства, возможно, связано с тогда ещё недавней миграцией с Win16 на Win32, а возможно, были и другие причины. Как бы то ни было, но многоплатформенность означала некую Незыблемую Правильность и Хороший Стиль.

Но эту программу никто на Макинтош переносить не помышлял. Даже 16-ти и 32-битная версии сильно отличались по своему строению (может, были какие-то небольшие общие куски, точно не помню). То есть ни о каком действительно многоплатформенном коде речи не шло. Небольшие различия для клонов 9x и NT, да и всё. Но тем не менее, вставки _MAC имели место быть.

Оказалось, что был один программист, который считал, что так будет правильно. Мол, нужно писать переносимый код. "Почему?" — спрашивали мы у шефа. "А он считал, что так надо. Вдруг, мол, будем на Макинтоше компилировать?", тут шеф хихикал в бороду: "Как этот Мак выглядит-то? Хоть кто-нибудь знает?"

В конце концов маковские дефайны остались в первых версиях исходников на SourceSafe. Жалеть, уж поверьте, не пришлось. Правильный подход в Хорошем Стиле, о котором с придыханием говорили гуру, закончился пшиком.
[история off]

Конечно, эта история ничего не доказывает. Стукнуло бы кому-нибудь в голову перенести программу на Mак, вот уж наигрались бы. Однако, история не знает сослагательного наклонения и главное, чуете родство моделей: "А так правильно... ибо вдруг..." Вот-вот, правильно чуете.

Тот же самый феномен я заметил и в оценках одиозного sprintf. Апофеозом мысли стало высказывание, что мол, если переполнение буфера может случиться, оно обязательно произойдёт. Нет, не произойдёт. Не потому, что пример нельзя переколпачить так, что вероятность переполнения увеличится, а потому, что в данном конкретном случае переполнения нет и оно не может случиться. Переколпакирование же — разговор отдельный, потому что изменённый код — это всегда новый код.

Возвращаясь к гранд-авторам компьютерной литературы, замечу, что то, что ими декларируется грешит излишней общностью, особенно, если это результаты исследований N команд. И их можно понять: представляете, какого размера были бы книги, если бы подробно излагались данные по каждому конкретному случаю? Поэтому такие выводы можно и должно учитывать, но вовсе не надо слепо переносить на каждый конкретный strcpy.

Это стало причиной моих язвлений по поводу "вредности чтения книг". Книги читать, конечно же, не вредно. Иногда — опасно. Опасно, когда харизма автора заслоняет rationale читателя. Опасно, когда чьё-то обобщённое наблюдение обращается в догму. Опасно, когда авторское "бывает" превращается в читательское: "точно будет!" Подчас из-за этого специалисты не пользуются огромными кусками инструментальных средств.

Причину такого ужесточения я могу только предположить: это желание иметь рецепт, который-всегда-работает. Желание окружить себя иллюзиями, что всё идёт "как надо" ибо "мы пользуемся правильными рецептами". Желание сие иррационально по существу: "Взял он три тысячи нужных вещей и уложил их на лодке своей." Вот вам проявление "парадигмы" в её худшей ипостаси. Освободите свой разум, коллеги, ну а ж... Смотрите "Взвод" в Гоблинской озвучке, или хотя бы вспомните: "Ведь для хорошего, для рыбака, удочка только нужна и река."

...

В заключение хочу поблагодарить активных участников.

Сначала оппонентов.

Дарнея — за невероятную настойчивость.
klapaucius-а — за неординарные формулировки.
VladD2 — за неожиданность.
WolfHound — за освежающие разговоры не по существу.

Теперь — пропонентов.

Cyberax — за последовательность.
eao197 — за спокойствие.
Kluev — за чёткость мысли.
McSeem2 — за угрюмость и совершенно шикарный "разнос" оппонента, у меня бы так не получилось.

А также остальных участников, перечислить коих нет ровно никакой возможности.

Разумеется, выражаю респект зачинщику — AlexLion. Правда, он почему-то растворился в пространстве.

Аплодисменты, занавес.

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

Давай теперь разберемся что же ты написал в данном сообщении:
1)Опять развел кучу думагогии.
А что тебе еще остается если аргументов нет?

2)В очередной раз отверг возможность изменения кода.
Тем самым превратив свой пример в сфероконя ибо реальный код имеет привычку меняться самым не предсказуемым образом.

3)Привел левую историю и на ее основе доказываешь (хотя ты и пытался от этого откреститься но именно это ты и делаешь) свою "правтоу".
А куда отправляют доказательства по аналогии?

4)Перешол на личности оппонентов.
Ай как не хорошо.

Итого: Ты в очередной раз продемонстрировал свое искуство демагогии.
Вот только демагогией невозможно доказать свою правоту.

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

WH>Давай теперь разберемся что же ты написал в данном сообщении:
WH>1)Опять развел кучу думагогии.
WH>А что тебе еще остается если аргументов нет?

Подобные утверждения в "Философии" — это как дежурное вступление. Точнее можешь выразить свою претензию?

WH>2)В очередной раз отверг возможность изменения кода.
WH>Тем самым превратив свой пример в сфероконя ибо реальный код имеет привычку меняться самым не предсказуемым образом.

Отверг? Нет. Я сказал, что изменившийся код — это, по сути, новый код.

WH>3)Привел левую историю и на ее основе доказываешь (хотя ты и пытался от этого откреститься но именно это ты и делаешь) свою "правтоу".
WH>А куда отправляют доказательства по аналогии?

Я только лишь показал, что нечто подобное уже видел. Кстати — не раз.

WH>4)Перешол на личности оппонентов.
WH>Ай как не хорошо.

Вот не буду тебе больше "спасибо" говорить прилюдно.

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

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

WH>>Давай теперь разберемся что же ты написал в данном сообщении:
WH>>1)Опять развел кучу думагогии.
WH>>А что тебе еще остается если аргументов нет?

ГВ>Подобные утверждения в "Философии" — это как дежурное вступление. Точнее можешь выразить свою претензию?

Не начинайте опять воду в ступе толочь, плз.

А можно я подрезюмирую ?

Очем тут можно спорить ? все очень банально.
1. Если задача ПОЗВОЛЯЕТ решение на safe языке/платформе то нет ни одной причины делать это на unsafe. Преимущества очевидны, стоимость , скорость разработки, стоимость сопровождения.

2. Если задача ТРЕБУЕТ unsave (строгий контроль памяти , производительность, сопряжение с библиотеками, маркетинг, кадры, переносимость и т.п.) то это неэфективно пытаться решать задачу по другому.

minorlogic wrote:
> Очем тут можно спорить ? все очень банально.
> 1. Если задача ПОЗВОЛЯЕТ решение на safe языке/платформе то нет ни одной
> причины делать это на unsafe. Преимущества очевидны, стоимость ,
> скорость разработки, стоимость сопровождения.
А как насчет:
1. Скорость работы.
2. Занимаемые ресурсы (объем на носителе, объем в памяти).

Это тоже факторы. Только safe-тусовка почему-то о них предпочитает не
говорить.

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

M>Очем тут можно спорить ? все очень банально.
M>1. Если задача ПОЗВОЛЯЕТ решение на safe языке/платформе то нет ни одной причины делать это на unsafe. Преимущества очевидны, стоимость , скорость разработки, стоимость сопровождения.

M>2. Если задача ТРЕБУЕТ unsave (строгий контроль памяти , производительность, сопряжение с библиотеками, маркетинг, кадры, переносимость и т.п.) то это неэфективно пытаться решать задачу по другому.

Противоречие тут несколько иное. Если кратко, то его можно выразить так: можно ли в рамках safe-подхода однозначно отбрасывать какие-то функции C? Одни утверждают, что можно, другие — нельзя.

Контекст здесь — C/C++. Сами по себе safe/unsafe платформы к делу отношения не имеют.

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

C>minorlogic wrote:
>> Очем тут можно спорить ? все очень банально.
>> 1. Если задача ПОЗВОЛЯЕТ решение на safe языке/платформе то нет ни одной
>> причины делать это на unsafe. Преимущества очевидны, стоимость ,
>> скорость разработки, стоимость сопровождения.
C>А как насчет:
C>1. Скорость работы.
C>2. Занимаемые ресурсы (объем на носителе, объем в памяти).

C>Это тоже факторы. Только safe-тусовка почему-то о них предпочитает не
C>говорить.

Я же сказал "ЕСЛИ ПОЗВОЛЯЕТ" т.е. быстродействие и расход памяти ПРИЕМЛЕМЫ для реешния данной задачи.

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

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

M>>Очем тут можно спорить ? все очень банально.
M>>1. Если задача ПОЗВОЛЯЕТ решение на safe языке/платформе то нет ни одной причины делать это на unsafe. Преимущества очевидны, стоимость , скорость разработки, стоимость сопровождения.

M>>2. Если задача ТРЕБУЕТ unsave (строгий контроль памяти , производительность, сопряжение с библиотеками, маркетинг, кадры, переносимость и т.п.) то это неэфективно пытаться решать задачу по другому.

ГВ>Противоречие тут несколько иное. Если кратко, то его можно выразить так: можно ли в рамках safe-подхода однозначно отбрасывать какие-то функции C? Одни утверждают, что можно, другие — нельзя.

ГВ>Контекст здесь — C/C++. Сами по себе safe/unsafe платформы к делу отношения не имеют.

Ну тогда я вообще глубоко не понимаю суть проблем , хоть и следил (украдкой) за ходом перепалок

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

А не слишком нагло сви резюмы на общую тему давать? Да еще отдельной темой?

У каждого резюмэ свое.

ЗЫ

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

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

C>А как насчет:
C>1. Скорость работы.

А что скорость? Давно доказано, что реального увеличения скорость использование С++ не надет. Реальная скорость приложения определяется его алгоритмами и качеством оптимизации узких мест.

C>2. Занимаемые ресурсы (объем на носителе, объем в памяти).

Объем на носителе? Бред какой-то. Байтод обычно компактнее бинарного (если ты о Яве с дотнетом). А память... Читай ниже.

C>Это тоже факторы. Только safe-тусовка почему-то о них предпочитает не
C>говорить.

Нет никаой сэйф-тусовки. Люди ратующие за ансэйф — это раздолбаи и маргиналы вредящие всему собществу (разлогающие его).

В даном же случае идет банальная подмена понятий "безопасный код" и "реализация VM для Явы или дотнета".
В исходной теме речь шла о С++. Не смотря на то, что язык на сквозь дырявый и грабельный, но все же при должной уситчивости и наборе "правил хорошого тона" и на нем можно писать отностиельно безопасно. И уж 100%-но если не любую, то многие задачи можно решать как небезопасно, так и безопасно.

Что касается выбора между sprintf и snprintf, то правильный выбор тут буте std::strung, CString или им подобные стринг-билдеры.
Слова же о том что "сэйф-тусовка считает snprintf безопасным" просто наглая лож. Более безопасным чем sprintf — да, но безопасным? Ни в коем случае. Сама реализация передачи списка параметров неограниченой длинны в С++ сделана так чудовищно небезопасно, что говорить тут не о чем.

Если говорить о языках, то есть тонна языков обеспечивающих и малый оверхэд, и намного лучшую безопасность чем С++. Те же клоны ML или, ни при детях будет сказано, Оберон. Да, даже D будет куда лучшем выбором, хотя он тоже не полносью безопасен. Вот только С++ популярен (читай разрекламирован). Вот и выбирают кулхацк-программеры и "бывалые" индустрии его. А возможно выбор определяется банально тем, что другого они ничего не знают. А потом они бегут искать скриптовые языки чтобы хоть как-то избавиться от всей этой жути хотя бы во внутреннем софте.

Сказки про медлительность дотнета и какие-то невероятные размеры исполняемых файлов (вообще новая сказка, кстати) — вранье. Правдой является только то, что дотнет-приложения жрут больше памяти. Ну, так один фиг они ее жрут куда меньше чем есть в системе и их хватает. Если брать мэйнстрим — софт для современных PC, а не экзотические случаи встраиваемых систем, то техника более чем готова/пригодна для использования дотнета. А стало быть, все слова про память просто дешевые отмазки.

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

ГВ>>Контекст здесь — C/C++. Сами по себе safe/unsafe платформы к делу отношения не имеют.

M>Ну тогда я вообще глубоко не понимаю суть проблем , хоть и следил (украдкой) за ходом перепалок

В бункере Гитлера идет секретное совещание.
Врдуг в бункер воходит Штирлиц с вазой апельинов.
Подходит к столу, ставит вазу, разворачивается и идет к сейфу.
Открывает его, берет от туда документы и ничего не говоря, разворачивается и уходит.
— Кто это был?
— А это русский разведчик Штирлиц.
— И что же вы ему даже ничего не скзали?!
— Так, все равно отвертися. Скажет, к примеру, что апельсины приносил.

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

ГВ>Очередной раунд баталии, кажется, завершён, оглянемся.

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

P.S. А тема топика очень близка мне, постоянно приходится принимать подобные решения (у нас в системе и safe C#, и unsafe C#, и С++ с разным уровнем "безопасности"). Но спорить ни с кем не буду — "лучше гор могут быть только горы, я себе уже всё доказал"

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

VD>Сказки про медлительность дотнета и какие-то невероятные размеры исполняемых файлов (вообще новая сказка, кстати) — вранье.

Одной из целью Singularity было создание среды в которой безопасный код не влек бы большого оверхэда, дословно "need not incur large performance penalties". Таким образом "вранье" нашло неожиданное подтверждение в Рэдмонте.

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

VD>А не слишком нагло сви резюмы на общую тему давать? Да еще отдельной темой?
VD>У каждого резюмэ свое.

Форум разве не для этого?

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

ГВ>>Контекст здесь — C/C++. Сами по себе safe/unsafe платформы к делу отношения не имеют.
M>Ну тогда я вообще глубоко не понимаю суть проблем , хоть и следил (украдкой) за ходом перепалок

Только в деталях. Именно в деталях и проявляются перекосы моделей. В том-то и фокус всей дискуссии.

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

ГВ>Форум разве не для этого?

Этот? Да, видимо.

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

ГВ>>Очередной раунд баталии, кажется, завершён, оглянемся.
A>Я основной тред почти не читал, но на резюме этот пост явно не тянет — свысока обвинил оппонентов в слепом следовании догмам, привёл какой-то странный пример, не имеющий отношения к топику (да даже если и имел бы отношение, делать выводы из одного примера — плохой стиль), перешел на личности оппонентов

Пример я подобрал специально и к теме топика он имеет наипрямейшее отношение. Я не раз об этом говорил. На личности оппонентов... Да, действительно, пришлось упомянуть "желание правильных рецептов", но иначе просто невозможно объяснить упрямое отстаивание использования snprintf в элементарном случае. Ratio здесь ограничивается сплошными "надо", "вдруг", "все" и прочими ссылками в никуда.

Так что, усмотреть "слепое следование догмам" оснований у меня было более чем достаточно. Остальное сказано в резюме.

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

ГВ>>Форум разве не для этого?
VD>Этот? Да, видимо.

Ух ты, как интересно.

VD>А не слишком нагло сви резюмы на общую тему давать? Да еще отдельной темой?
VD>У каждого резюмэ свое.

Так пусть резюмируют, если есть что сказать. Я же рот никому не собираюсь затыкать, в отличие от.

Извиняюсь, что «влезаю», но:

VD>Сказки про медлительность дотнета и какие-то невероятные размеры исполняемых файлов (вообще новая сказка, кстати) — вранье.

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

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

По поводу памяти уже кто-то не так давно говорил примерно следующее, что в линуксе, свободная память может браться системой для кеширование файловых операций и так вот «просто растачать» память, как это делают дотНЕТ приложения — немного странно.

VD>Если брать мэйнстрим — софт для современных PC, а не экзотические случаи встраиваемых систем, то техника более чем готова/пригодна для использования дотнета. А стало быть, все слова про память просто дешевые отмазки.

Встраиваемые системы — это не экзотика. Это будущее. Кажется ещё год тому назад Бил Гейтс сказал, что эра настольных компов закончилась. МС вот всерьёз заняласть Windows Mobile и двигает её в телефоны. Windows Media тоже не совсем в нормальных компах работает.

Техника готова — эта правда, кто спорит. К сожалению, профайлы не работают и не могу взглянуть, где вы находитесь, но вот в моей конторе, в калифорнийском офисе (да и в моём тоже), компы простые (у многих до сих пор LCD мониторы), правда есть народ, работающий на ноутбуках от Делл. Но они купленны года 2 — 3 тому назад и обмен ещё не скоро будет.
Не думаю, что ради каких-то программ, даже нужных в бизнесе, будет так же производится обновление железа, скорее всего будет искаться аналог, удовлетворяющий текущим характеристикам компов.