(no subject)

[stas]

Про buffer overflows и т.п.. Кстати, опыт PHP (не только, конечно, просто с PHP пример наиболее близкий и распространённый) наглядно доказывает, что разруха - в головах. PHP лишён проблем с управлением памятью и т.п., присущих C[++] - т.е. никаких buffer overflows, memory corruption и т.п. в нём сделать практически невозможно - однако проблемы с безопасностью в весьма распространённых программах на PHP довольно часты. Потому что плохому танцору никакие сапоги-самоплясы не помогают, как видно.

Comments

[arbat.livejournal.com]

Единственные проблемы C++ с управлением памятью, которые мне известны - это проблемы связанные с имплементацией lock-free concurrency.

Все остальные проблемы - это проблемы не языка, а программистов.

[ivan-gandhi.livejournal.com]

Как программист программисту, скажите мне вот такую вещь: в джаве я могу написать что-нибудь вроде

int idx(String container, String contained) {
return container.toLowerCase()indexOf("/" + contained);
}

то есть, могу свободно писать f(g(x), h(y)), где g и h возвращают какие-то объекты, не задумываясь при этом не только о распределении регистров, но и о необходимости удалить ненужные объекты, после того, как f ими воспользовался.

А как в таком случае поступит сиплюсплюс программист? Или сиплюсплюс программист считает функциональное программирование вредной буржуазной выдумкой?

[relyef.livejournal.com]

Как программист программисту, я бы Вам посоветовал не позориться, а скомпилировать этот код на С++, а вдруг получится. Вставив точку перед indexOf. A потом я бы посоветовал задуматься об эффективности подобного кода, что на Java, что на С++.

[arbat.livejournal.com]

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

[stas]

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

[arbat.livejournal.com]

Хм.
Ну, то, что Вы написали, переводится на C++ вот так:

size_type idx(const std::string& container, const std::string& contained)
{
    return container.find(contained, 0);
}

Я не очень понял пример чего Вы приводите, при чем тут функциональное программирование, распределение регистров и необходимость удалять объекты. Я совсем не понял агрессивный тон.

Далее, каждый язык хорош для того, для чего он сделан. И, хотя есть библиотеки, дающие возможность заниматься функциональным программированием на C++ (или Джаве), но ведь можно и гвозди забивать плоскогубцами, да?

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

[stas]

В C++, однако, возможен доступ к памяти, не принадлежащей обьекту или принадлежащей не тому обьекту, к которому намеревались доступаться. Средствами языка, причём. Тяжёлое наследие C и т.п. Однако я говорил о том, что даже уничтожив эту возможность, мы лишь заменим одни проблемы на другие, не лучшие. Довольно очевидная мысль, вообще-то, но как ни странно, многие её упускают.

[arbat.livejournal.com]

C++ дает определенную свободу, да. Но, однако, это не есть проблема этого языка. Русский язык тоже дает возможность употребить глагол женского рода в сочетание с существительным мужского, но сие не означает, ни того, что это - "тяжелое наследие", ни того, что не имеющий этой проблемы английский язык имманентно более грамотен.

[stas]

Я, в общем-то, об этом и писал. Слово "проблема" я употребил не в смысле "проблема, присущая языку", а в смысле "проблема, часто встречающаяся у его пользователей". Вроде как в английском можно ошибиться, забыв поставить артикль, а в русском - нет, т.к. нет артиклей :)

[arbat.livejournal.com]

Ну, так и формулируйте точнее: "часто встречающаяся безграмотность среди тех, кто хреново знает язык, такая: ..."

[digest.livejournal.com]

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

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

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