[C++] В чем писать? | Разочаровался в emacs'e

kdevelop

В общем С++ требует хорошее автодополнение

самое лучшее есть в еклипсе. Я его и использую, вместе с qt. Все хорошо, но есть ложка дегтя - сложно отлажваить, qt типы прочитать невозожмно

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

Про автодополнение - вы использовали последнюю версию Cedet?

> Про автодополнение - вы использовали последнюю версию Cedet?

Я не верю в emacs. Вообще за свою жизнь более или менее адекватный подсказчик у eclipse, причем последней. Он еще может прорваться через 4 вложеннных шаблонов и 3 шаблоных метода подрят, но на 4 уже пассует

Поэтому я бы не рекомендовал eclipse для серъезной работы с С++

Суровые поцоны не нуждаются в автодополнении!

Лично я в Emacs нашёл всё, что мне надо. Посети страницу ott-а

Za razrabotku v debug'ere nado rasstrelivat'.

> Про автодополнение - вы использовали последнюю версию Cedet?

Да последнию, с моим простым классом который лежит в директории проекта автодополнение работало, с классами QT работать отказалось, хотя я указывал путь до библиотек qt, но в емаксе инклуды подсвечивались красным (типа не найдены библиотеки), приходилась в емаксе открывать все библиотеки которые я подключал и там набирать c++-mode, и только тогда они подсвечивались желтым, и индексировал их, подсветка пропадала, но автодополнение не в какую не работало.

> Суровые поцоны не нуждаются в автодополнении!

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

> Посети страницу ott-а

В основном благодаря ей я и допиливал свой емакс

> Za razrabotku v debug'ere nado rasstrelivat'.

А значение переменных вы угадывать будите? Или через cout выводить?

> при работе с новым неизвестным классом, оно ой как помогает.

В любом большой проекте 90% классов неизвестны. Даже те, что ты писал недели 3 назад. Так что без него не как

> А значение переменных вы угадывать будите? Или через cout выводить?

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

В программах с очередью сообщений, и непоследовательным исполнением это особо актуально

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

По твоей логике дебаггеры вообще не нужны. Каждая вторая строчка в твоей программе это prinf?

>По твоей логике дебаггеры вообще не нужны. Каждая вторая строчка в твоей программе это prinf?

почти. покрытие trace'ами - хороший стиль в любом сколько-нибудь сложном проекте. а trace scopes задают иерархию

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

Netbeans

Автодополнение для C++ там ИМХО лучше, чем в эклипсе и qtcreator

А в QT creator присутствует автодополнение чего либо кроме самого QT?

Собирай софт с -O0 -g3. Дебаггер не может показывать переменные, которых нет (соптимизированы до регистров), не может ставить брейкпойнты на места, которые не существуют в превоначально задуманном автором виде. gdb в емаксе - обычный gdb, даже с каким-то нафиг не нужным гуём. gdb тоже обычно не нужен, разве что крешдампы изучать. Вообще, залез на кактус, плачь, но продолжай есть, пока не станешь суровым девелопером.

>По твоей логике дебаггеры вообще не нужны. Каждая вторая строчка в твоей программе это prinf?

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

Ибо просты ошибки находятся в ходе peer review или coverity находит. А сложные логические дебаггер не помогает (а скорее мешает) искать. Ибо лучше просто вдумчиво посмотреть в код, проанализировать поведение программы и сопоставить.

P.S. Дебажных принтов в нашем коде очень мало так что это не вариант.

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

Не создавай себе конкуренцию :) Пока основная масса юниксовых программистов будет "вчера слез с лицензионной венды и пирацкой 2008-й студии, не нашёл красиво выглядещего редактора", все серьёзные заказы будут нести таким, как ты ;)

Эх, когда же появятся настоящие программисты, которые тоже слезли на линукс с венды, но им непонятны настоящие вопросы? Например, что такое vdso, чем правильно отслеживать, на сколько программа в сисколле застревает?..

> Да последнию, с моим простым классом который лежит в директории проекта автодополнение работало, с классами QT работать отказалось, хотя я указывал путь до библиотек qt, но в емаксе инклуды подсвечивались красным (типа не найдены библиотеки), приходилась в емаксе открывать все библиотеки которые я подключал и там набирать c++-mode, и только тогда они подсвечивались желтым, и индексировал их, подсветка пропадала, но автодополнение не в какую не работало.

посмотрел я на qt'шные инклуды - судя по всему там надо достаточно сильно настраивать таблицы препроцессора.... Хотя с моей точки зрения, за такое кол-во макросов надо расстреливать :-(

> Пока основная масса юниксовых программистов будет "вчера слез с лицензионной венды и пирацкой 2008-й студии, не нашёл красиво выглядещего редактора"

Мой вопрос и заключается в том что продолжать грызть кактус или нет. Ибо приемуществ в emacs'e по сравнению с современными IDE я не увидил (за исключением удобных хоткеев) а если есть IDE более функциональная и более удобная то почему бы не использовать ее. Я же не понтоваться хочу типа "вот я использую редактор в котором мне приходится делать все вручную, значит я крутой".

> посмотрел я на qt'шные инклуды - судя по всему там надо достаточно сильно настраивать таблицы препроцессора.... Хотя с моей точки зрения, за такое кол-во макросов надо расстреливать :-(

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

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

Для этого нужно изменить подход к разработке софта с tools-oriented на task-oriented.

Давным давно, когда я тоже интересовался Qt и настройкой Emacs (но сейчас он у меня почти в дефолтном конфиге, только пара хуков для расстановки переновов добавлена), я нагуглил статью, в которой поэтапно делалась IDE для Qt из Emacs под венду. Там вроде автокомплит Qt работал, так что копай в гугл))

> IDE более функциональная и более удобная то почему бы не использовать ее

emacs это не IDE

вот в этом и отличие

> А можно подсказку в каком направление копать? А то мне фраза настраивать таблицы препроцессора вобще не понятна, что это значит и как это делается.

Существует два варинта, похожих друг на друга. Можно указать таблицы препроцессора (пары имя/значение) в переменной semantic-lex-c-preprocessor-symbol-map, тогда они будут применяться для всего кода анализируемого Semantic. А можно сделать это для отдельных проектов, определенных через EDE - тогда надо использовать параметр :spp-table при определении проекта.

Вообще, надо бы обсудить с автором Cedet разбор инклудов от Qt - у меня есть подозрение, что он на нем не программирует :-)

> Вообще, надо бы обсудить с автором Cedet разбор инклудов от Qt - у меня есть подозрение, что он на нем не программирует :-)

А я думаю надо переставать кушать кактус

переставайте, ради бога, я-то тут при чем? я кактусы не ем

> Например, что такое vdso, чем правильно отслеживать, на сколько программа в сисколле застревает?..

Дай я догадаюсь - ты SystemTap занимаешься? :D

> Дай я догадаюсь - ты SystemTap занимаешься? :D

Таки спалился... :(

> переставайте, ради бога, я-то тут при чем? я кактусы не ем

Ну не умеет он анализировать сложные шаблоны, не умеет

>А в QT creator присутствует автодополнение чего либо кроме самого QT?

Простые классы и темплейты вроде как дополняет. А stl не очень.

> Ну не умеет он анализировать сложные шаблоны, не умеет

Я вам более того скажу: сложные шаблоны далеко не все плюсатые программисты умеют анализировать. А если программист ориентирован на дебаггер, так он ещё и отладить сложно сломанный шаблон не сможет.

> Ну не умеет он анализировать сложные шаблоны, не умеет

Блин, а мужики-то и не знают.... Так и запишем, в boost.spirit несложные шаблоны...

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

Прочитал не все программы...

А программистов, которые могут писать на шаблонах хорошо - мало

А вот если у тебя еще boost::funtion - то вы вообще ничего в дебагере только не сделаете

Выход прост, на самом деле - не использовать C++

jtootf, imp, вы перевернули с ног на голову смысл моего высказывания.

Я рад что вам не редко нужен деббагер. Он действительно по мере роста опыта программиста всё меньше и меньше нужен. Но это не значит что раз кто-то из "больших прогеров" забил на деббагер то и всем остальным он не нужен. Мне вот нужен :). Особенно для отладки чужого кода в который кто-то забыл вставить "деббаговые принты". Но и для своих вещей тоже не мешает. Глазками просмотреть это одно а как оно на самом деле исполняется это другое.

Деббагер это просто один из инструментов, речь не идёт о зацикленности только на нём(это я про tools-oriented).

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

А эти трейсы не могут повлиять на результат выполнения программы добавляя те же задержки?

Кстати, каких хоткеев нехватает в Creator? Imho в смысле хоткеев тав все отлично. В любом случае - у них весьма активный maillist, можешь туда написать. Afair там весьма оперативно сделали FakeVim для нуждающихся. =)

Посмотри еще valgrind - мегатулза для отлова утечек памяти(--leak-check=full), случайных падений(--db-attach=yes), профилировщик(--tool=callgrind), race-conditions(этот режим я не особо осваивал) и т.д.

Спасибо, я с valgrind не расстаюсь :).

Переход на начало и конец строки не настраиваются, например.

>Netbeans ненене, вот Netbeans втопку.

Тем более, если уж Eclipse топикстартеру показался "не линуксовым".. Да и не кошерно это писать на плюсах в джавовской IDE

valgrind - не панацея :-) особенно на сложных проектах

Не панацея, но иногда сильно экономит время. Например если падения не воспроизводимы или не всегда в одном месте, и не весь код ты знаешь как свои пять пальцев.

А так - серебрянных пуль пока не отливают. =)

Интеграция с дебагером в Emacs убога и с этим мало что можно поделать. Но с правильными трейсами в программе и с valgrind вполне можно обходиться практически без дебагера. Больше читать и понимать код приходится, конечно, но это только на пользу проекту.

А вот с поддержкой С++ в Emacs плохо, единственное что его спасает - Xrefactory, всякие cedet еще очень не скоро допилят до качественного front end для C++. Но xref не бесплатный (хотя триал легко обходится), и довольно тормознутый по сравнению с Eclipse CDT, т.к. более полно разбирает код (даже по нескольку раз в случаях с #ifdef). Xref - это самый надежный разборщик кода на плюсах (лучше чем Eclipse/Netbeans/VisualAssist/SlickEdit), его Find References и макросы в Emacs позволяют творить просто чудеса в плане рефакторинга кода.

> посмотрел я на qt'шные инклуды - судя по всему там надо достаточно сильно настраивать таблицы препроцессора.... Хотя с моей точки зрения, за такое кол-во макросов надо расстреливать :-(

Кстати, а почему в cedet не сделают такую же простую настройку всех этих include dirs и defines как в Eclipse/Xref, когда просто все вызовы g++ логируются и разбираются (в них и содержится вся нужная информация)? Ведь нужно только один раз собрать проект и сразу все эти настройки становятся известны и не нужно ничего самому нигде указывать...

патчи приветствуются... :-)

а иногда просто ничего не находит :-) осбенно если ошибка воспроизводится только под нагрузкой

Ну, можешь ещё Neteans попробовать для разнообразия - http://www.netbeans.org

А зачем для C++ вообще что-то допиливать? C++ мертв. Перспектив у него никаких, светлого будущего с ним не связано, а то что для него есть - и так хватает.

> патчи приветствуются... :-)

Не, я не насколько суров, чтобы так отчаянно пилить инструмент :) Предпочитаю и сравниваю в основном готовые решения.

> А зачем для C++ вообще что-то допиливать? C++ мертв. Перспектив у него никаких, светлого будущего с ним не связано, а то что для него есть - и так хватает.

Существует огромная куча уже имеющегося кода на плюсах, которую надо как-то поддерживать и дорабатывать. Хотя бы для этого нужно допиливать инструменты.

А вообще, критикуешь - предлагай. Что у нас сейчас живое, перспективное и ведущее в светлое будущее? И сколько реальных приложений на этом написано?

Вобщем я так посмотрел за сегодня еклипс, qt creator поковырял и решил остаться на Емаксе, надеюсь cedet будет развиваться и когда нибудь там появится хорошее автодополнение, а пока буду пытаться почувствовать себя суровым прогером :) Кстати из всего что я смотрел больше всего понравился qt creator.

> А зачем для C++ вообще что-то допиливать? C++ мертв. Перспектив у него никаких, светлого будущего с ним не связано, а то что для него есть - и так хватает.

Обоснуй? Что сейчас актуально? Помоему С++ это мощный язык и конец его не скоро.

лично меня vim устраивает

раньше пользовался codeblocks