Привести в порядок знания по Си++

> # Какие-либо вспомогательные средства разработки. Не верю, что до сих пор ничего лучше дебаггера для отладки не придумали.

это как? Разве что-то для отладки - не является дебаггером по определению? Существуют всякие memory overrun/underrun/leak детекторы, логгеры, инвариант-чекеры и т д, но если уж дошло до отладки - без отладчика тут не обойдешься :-)

но если уж дошло до отладки - без отладчика тут не обойдешься :-)

Личные наблюдения за гуру показывают, что гуры пользуются мозгами для анализа кода и, реже, дебажными принтами. Ну ещё strace/systemtap, но это можно считать дебажными принтами. gdb/crash юзают крайне редко, и то, для анализа дампа постмортем.

+плюсую.

Когда не работал дебаггер в фортране, print'а хватало, хотя не всегда и удобно.

Как там дела в емаксе с дебаггером? Удобно ли пользоваться? И можно ли для с++ твой конфиг для емакса?

Как там дела в емаксе с дебаггером? Удобно ли пользоваться?

Удобно. Дебаггер в интерактивных средах - это совсем другое дело. Ещё trace.el клёвая штука.

И можно ли для с++ твой конфиг для емакса?

У меня слабый плюсовый конфиг, я на плюсах сейчас крайне редко пишу. Традиционно мощный конфиг у Алекса Отта: http://github.com/alexott/emacs-configs

Спасибо.

Правильно ли я понимаю: дебаггер в интерактивных средах - тыкание по кнопкам, а емаксе - в виде комманд в нижней командной строке?

>Личные наблюдения за гуру

Много гуру видел?

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

Потому что перед этим выработали свои знания, пользуясь отладчиком. Без него это непродуктивно. Тем более потом удалять эти printf или уродовать код препроцессорными вставками.

> Собственно, сам Си++.

Стандарт. Говорят, Страуструп тоже хорош, мне стандарта хватало.

Язык шаблонов.

C++ Templates - The Complete Guide

Необходимый минимум библиотек: stdlib,

The C++ Standard Library - A Tutorial and Reference

boost

Стандартная документация.

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

valgrind - надо памятник создателям ставить, имхо.

Ипользуются хоткеи. В кнопки тыкать тоже можно.

Правильно ли я понимаю: дебаггер в интерактивных средах - тыкание по кнопкам, а емаксе - в виде комманд в нижней командной строке?

Конкретно в емаксе ты видешь всё тот же буфер с текстом программы, только все данные уже живые. Можно также делать step'ы, менять значения переменных и т.п.

Много гуру видел?

Минимум, двух самого высокого класса вижу каждый день ;)

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

Отладчиком (STS!) я пользовался на Спектруме, когда в детстве писал на ассемблере. Отладчиками для высокоуровневых языков не пользовался. Да и неудобно это, и не всегда возможно.

Тем более потом удалять эти printf или уродовать код препроцессорными вставками.

Ядро с utrace + systemtap в руки. Или syslog/log4<твой_язык>, там можно в рантайме говорливость менять.

Сам С++ по стандарту осиливали, а шаблоны и стандартную библиотеку по стандарту не осилили видимо.

А что за systemtap и utrace? Можно пример использования?

http://13-49.livejournal.com/77006.html

>Язык шаблонов.

1)Александреску, 2)Стив Мейер 3) Стив Макконнел

Необходимый минимум библиотек: stdlib, boost, может быть, что-то еще.

STL, APR, ACE, Loki иногда тоже нужен

Паттерны и антипаттерны.

GoF паттерны проектирования (есть на русском, недавно вышла) Антипаттерны — книжка так и называется, на русском не видел. Очень правильная книжка с примерами «как не надо делать»: концептуально на уровне процесса/идеи/дизайна, неправильный выбор реализации, неправильный выбор инструментов для реализации.

можно включить что-нибудь про UML, SADT, IDEF и т.п.

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

«Why Programs Fail?» и идею дельта-дебаггинга, то есть локализация/кластеризация множества конфигурационных параметров на стабильные и вызывающие сбои изменения.

Что-нибудь про юнит-тестированию, ибо без него никуда

Что-нибудь по continuous integration, ибо С++-ники обычно не знают весь процесс в целом, «просто кодеры». Вообще юнит-тесты, автодокументация( javadoc, doxygen) и интеграция — это теоретический минимум ява-кодера, но для с++ и оно иногда является откровением свыше.

«Howto write shared libraries» Ульриха Дреппера, есть несколько неочевидных моментов для gcc с visibility, version scripts, и т.п. Для gcc4 стало более актуально ибо visibility по умолчанию поменялся.

«Linkers and loaders», чтобы понимать как работает в целом компилятор/си рантайм/С++ рантайм/статический линкер/динамический линкер/загрузчик в ядре.

последние 2 темы нужны, так же как знание о «Fragile Base Class Problem» и понимание, что такое «стабильное ABI» для того, чтобы лучше делать библиотеки.

>но если уж дошло до отладки - без отладчика тут не обойдешься :-)

race condition тоже отладчиком отлажёвывать собираешься? хотя, если хорошо заскриптовать gdb, может и он что-то поймает

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

Потому что перед этим выработали свои знания, пользуясь отладчиком.

Далеко-далеко не факт. Я «выработал свои знания» мозгом и отладочным ввыводом + проверкой целостности структур данных в критических местах в программе

Без него это непродуктивно.

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

Тем более потом удалять эти printf или уродовать код препроцессорными вставками.

Ты заблуждаешься.

Обычно используют assert'ы/abort'ы и логирование(sic!). Логирование совсем не значит «уродование» кода препроцессорными вставками :)

> Ядро с utrace + systemtap в руки.

dtrace забыл! ж)

Ну как обычно - Мейерса, Страуструпа, Александреску. Это базовый минимум, чтоб разгребтись.

>проверкой целостности структур данных в критических местах в программе

И как это сделать без отладчика? Например, для map из C++ Std.

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

Если отладчика нет для их архитектуры - поверю. Только медленно это, много лишних кругов наматывается, пока найдешь, в чем проблема.

Обычно используют assert'ы/abort'ы и логирование(sic!).

Assert и abort сложных условий не проверишь. Максимум i < maxlen и так далее.

>Необходимый минимум библиотек: stdlib, boost

boost

нифига себе необходимый минимум.

> Если отладчика нет для их архитектуры - поверю. Только медленно это, много лишних кругов наматывается, пока найдешь, в чем проблема. Поинтересуйтесь когда появился отладчик для ядра Linux и как к нему относится Линус

> boost

толсто

Systemtap хороший, судя по этому посту его стоит изучить.

А что не так с boost? Или он не нужен?

> 1)Александреску Без твердых знаний С++ и реального опыта (хотя бы 2-3 года) читать КАТЕГОРИЧЕСКИ не рекомендую. Есть шанс испортить свой стиль программирования на долгие годы.

2)Стив Мейер

Хто это? Вероятно Scott Meyers с серией «Effective C++/STL». Полная противоположность Александреску - советы для самых маленьких. Часть про STL и синтаксис C++ - полезные, по оптимизации и архитектуре - довольно спорные. Пролистать вполне достаточно.

3) Стив Макконнел

Толстые книжки ни о чем. Сразу видно - Microsoft приложила свою грязную лапу. Годны разве что как запасной рулон туалетной бумаги или как подставки под горячее. Особенно ненавижу Code Complete - слишком много хомячков молится на ее безумную толщину.

GoF паттерны проектирования (есть на русском, недавно вышла)
Антипаттерны — книжка так и называется, на русском не видел.

«Паттерны» можно освоить только на реальном коде. Читать GoF стоит только для закрепления. «Как не надо» - тем более лучше на реальном коде. Заодно поймешь, почему именно не надо :3

можно включить что-нибудь про UML, SADT, IDEF и т.п.

Имеет смысл читать разве что «UML distilled» - он короткий и наглядный. Диаграммы классов не нужны, остальное может пригодиться.

(...хуета...)

Остальное - о мелочах, которые постигаются в процессе работы.

Касательно C++ - трупа читать не обязательно, книжка у него рыхлая, неполная и бессистемная. Тем более что какие-то знания уже есть. Лучше почитать что-нибудь общее, вроде «C++ gotchas» и рваться в бой.

В бою пригодятся: 1. STL - достаточно онлайн справочника. 2. boost - есть «Introduction to Boost», затем курить доки. 3. Qt - замечательные доки, с туториалами и прочими HOWTO. 4. шаблоны - «C++ Templates», но лучше не увлекаться.

ACE/Loki/Poco/(...прочий хлам...) - не нужны.

Когда появится реальный опыт, можно начать читать книги посерьезнее. Например, мою любимую - «Ineffective C++: Practical Solutions for Real Life».

Также советую обратить внимание на биндинги (Lua, Python, ...) и инструменты кодогенерации (moc из Qt, генераторы парсеров ...). И не забывать простой C - он еще нас переживет ;3

Из вспомогательных, можно юзать valgrind. Утечки памяти и где segfault находит хорошо. Хотя если вы юзаете сложные либы, то они часто сами управляют памятью и valgrind будет на них ругаться