Можно писать на C++ без утечек памяти?

Поток сознания.

>Стали закрадываться подозрения, что навороченные возможности C++ попахивают булшитом для проекта по одной, но очень важной причине: они не избавляют ПОЛНОСТЬЮ от необходимости держать в голове подробности реализации, иначе можно запросто зевнуть освобождение памяти или обратиться к нулевому указателю.

Это ИМХО надо делать в любом языке программирования.

ну вообще-то неинициализированных указателей при грамотном использовании std::auto_ptr/boost::shared_ptr/array не бывает в принципе.

// wbr

Да

>держать в голове подробности реализации

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

Да.

> Вопрос в том возможно ли так писать ПРАКТИЧЕСКИ

Да, только надо заставить себя писать правильно :-)

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

Короче, если позволяет время, то пиши на C++. Если нужен срочно результат, возможно стоит попробовать java.

Писать можно, но экономически нецелесообразно. Вообще С++ плохо подходит для больших проектов. Узких мест где нужна скорость довольно мало, а ошибки могут возникнуть везде. То есть лучше взять что то более безопасное и высокоуровневое, а если не хватает скорости, найти профайлером узкие места и переписать на С/С++. Тем более для прототипирования С/С++ совсем не подходит.

нет

> Писать можно, но экономически нецелесообразно. Вообще С++ плохо подходит для больших проектов. Узких мест где нужна скорость довольно мало, а ошибки могут возникнуть везде. То есть лучше взять что то более безопасное и высокоуровневое, а если не хватает скорости, найти профайлером узкие места и переписать на С/С++. Тем более для прототипирования С/С++ совсем не подходит.

просто интересно - а что вы подразумеваете под термином "большой проект"? это сколько?

// wbr

> И знать узкие места тех же "умных" указателей (типа шаблонного auto_ptr). "Сверхусилия" не нужно прикладывать никогда, если четко знаешь что тебе нужно и используешь соответствующий ЯП подход.

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

OCaml ftw

А что делать, когда проект большой и критичный к скорости код занимает более 90%?

>А что делать, когда проект большой и критичный к скорости код занимает более 90%?

(Стреляться || Искать кучу бабла на крутых спецов) :)

Если руки прямые, можно из гавна замки строить

> просто интересно - а что вы подразумеваете под термином "большой проект"? это сколько?

Ну я думаю начиная от 100 000 строк

>> просто интересно - а что вы подразумеваете под термином "большой проект"? это сколько? > Ну я думаю начиная от 100 000 строк

понятно. работал и в таких, причём 90% C++ и тяжёлое наследие от C. не смотря на последнее и то, что над проектом в разное время трудилось под сотню человек, тем не менее вполне стабильно летает. никаких претензий к языку. естественно подразумевается, что разработчики владеют им в достаточной степени.

// wbr

> Если руки прямые, можно из гавна замки строить

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

// wbr

> интересно посмотреть на живой пример такого замка. чтобы утверждение не было столь голословным.

Eclipse?

Ещё ~500 строк к проекту - и будешь иметь код, который укажет тебе на утечки и неинициализированные указатели. Правда, в рантайме.

Если писать много юниттестов и прогонять их под valgrind-ом (естественно исправляя всё, на что он ругается), то код будет вполне стабильным.

> Eclipse?

а что не так с эклипсой? как раз этот проект год от года лишь матереет и улучшается, не смотря на обилие разношёрстных команд, архитекторов, кодеров, стандартов и хотелок.

// wbr

он тактично назвал эклипс замком а джаву говном.

> он тактично назвал эклипс замком а джаву говном.

Как хорошо, когда тебя понимают :)

>> он тактично назвал эклипс замком а джаву говном.
> Как хорошо, когда тебя понимают :)

но в то же время плохо, когда не аргументируют свои заявления :-/

// wbr

Данный вопрос сабжа подробно освещен тут http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=1#4576462 тут http://forum.ixbt.com/topic.cgi?id=26:33626 и тут http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=1#4576462 Рекомендую обратить внимание на "При том, что оппонент сделал одну серьёзную и типично Сишную ошибку (запутался в типах, в результате затерлись нужные данные), а я одну мелкую и "общую" (перепутал тип поля в БД)"

> Данный вопрос сабжа подробно освещен тут http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=1#4576462 тут http://forum.ixbt.com/topic.cgi?id=26:33626 и тут http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=1#4576462 Рекомендую обратить внимание на "При том, что оппонент сделал одну серьёзную и типично Сишную ошибку (запутался в типах, в результате затерлись нужные данные), а я одну мелкую и "общую" (перепутал тип поля в БД)"

данный вопрос действительно подробно освещён не в проножурналах а на http://www.gotw.ca/gotw/index.htm

// wbr

>Вот, сверхусилия не нужны, но внимание рассеивается и можно чего-нибудь забыть.

Это общечеловеческая проблема :)

На паскале можно

Можно.

Использовать boost::shared_ptr, boost::weak_ptr вместо указателей. На голые указатели наложить запрет (ну без фанатизма - если ситуация требует напрмер для работы с буфером, передача в другие компоненты, профайлер сказал, что в этом месте ботелнек, ... - то юзать raw указатели даже нужно).

Также не использовать масивов, а всесто них std::vector<T> и boost::array<T>.

По возможности (если профайлер позволяет) - надо использовать готовые алгоритмя и контейнеры (STL, boost, ...) - они достаточно оттестированы и вероятность что вы отгребете ошибки значительно меньше, нежели если бы вы писали сами.
Если скорость контейнера вас не устраивает - посмотрите в сторону оптимизировать контейнер, а не переписывать его на свой.

Используйте валгринд.

ЗЫ. от проблем аля дедлоки, обращение к невалидному итератору, рейс кондишен вас никто не спасет

> А что делать, когда проект большой и критичный к скорости код занимает более 90%?

Умертвить архитекторов, нанять новых, которые напроектируют критичную к скорости часть в пределах 20%

>> А что делать, когда проект большой и критичный к скорости код занимает более 90%?

>Умертвить архитекторов, нанять новых, которые напроектируют критичную к скорости часть в пределах 20%

А если это вычислительная либа?

>Вопрос в том возможно ли так писать ПРАКТИЧЕСКИ, не прилагая сверхусилий и получая правильный код? Или C++ здесь не годится?

можно, годится(нужен опыт)

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

Улучшается -- да, но никак не стабилизируется и не ускоряется. Вот работаю вторую неделю с 3.3, так после 3.2 хоть и стал пофункциональнее, а плеваться хочется больше.

> Стали закрадываться подозрения, что навороченные возможности C++ попахивают булшитом для проекта по одной, но очень важной причине: они не избавляют ПОЛНОСТЬЮ от необходимости держать в голове подробности реализации, иначе можно запросто зевнуть освобождение памяти или обратиться к нулевому указателю.

Назовите язык где можно ПОЛНОСТЬЮ абстрагироваться от реализации, без рисков выедания памяти или тормозов?

Непонятно, почему претензии именно к C++? Обратиться к нулевому указателю можно и в Java, и даже NullPointerException поймают, далеко не факт что программа после этого останется в рабочем состоянии. Зачастую не работает даже выход и программу приходится убивать.

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

Не надо C++ винить, плохому танцору известно что мешает и java/С# от этого не спасают

Ответ элементарный — сначала думаешь, потом пишешь. Продуманное проектирование, документация, четкие контракты — и об отладчике, valgrind'е и так далее можно практически забыть. Даже тупые representation checks сами по себе позволяют контролировать большинство ошибок. И неважно — C, C++, Java — не brainfuck, и уже хорошо.

> но в то же время плохо, когда не аргументируют свои заявления :-/

А я ничего и не заявлял, просто сложил два + два :)

можно конечно, просто надо думать головой перед тем как писать, и если уж пишешь, что пользоваться smart pointers и прочими вещами, которые уже давно придуманы человечеством

>>> А что делать, когда проект большой и критичный к скорости код занимает более 90%?

>>Умертвить архитекторов, нанять новых, которые напроектируют критичную к скорости часть в пределах 20%

>А если это вычислительная либа?

Если речь идёт о математичиских вычислениях. То лучше оптимировать путём поиска или разработки подходяших математических алгоритмов. В этом случае скорость сходимости (?) (Rate of convergence) поважнее будет. Написать тестовый алгоритм в scipy ,octave,scipy или R-lang. Потом уже можно оптимировать например путём замены критичного кода старыми добрыми и десятилетиями проверенными фортран кодами.