LINUX.ORG.RU

Ответ на: комментарий от kemm

>Там каждый раз рзные люди. 8))
это, что то меняет?

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

>Они бесплатные, а не стоят 300 баксов, не умея нифига сверху того, что умеют вменяемые бесплатные редакторы/IDE.

xrefactory - действительно стоящая вещь для emacs, но стоит 400$
а все, что бесплатное не дотягивает до уровня visual assist, slickedit

acefsm
()
Ответ на: комментарий от kemm

я сам зарабатываю себе на жизнь
вам сколько платят за троллинг?

acefsm
()
Ответ на: комментарий от twosev

>> Не парься, то кто пишут без отладчика, пишут в основном только на форумах.

>Золотые слова.

И как же Линус написал Линукс, не послушав местных "экспертов"...

anonymous
()
Ответ на: комментарий от acefsm

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

Дооо... То-то ещё ни один из платных аналогов по удобству не смог обогнать vim, а по фичастости хорошо если догнал...

> а все, что бесплатное не дотягивает до уровня visual assist, slickedit

Доооо... В прошлый раз при попытках доказательства этого тезиса мы застряли на первой итерации, вроде? 8))

> я сам зарабатываю себе на жизнь

Я разве спорю? Например, неплохая прибавка к заработку, наверное, рекламировать сликеди на лоре... 8))

> вам сколько платят за троллинг?

Я таки делаю это из любви к искусству. А вы таки хотите меня переманить? Таки я жду ваших предложений! 8))

kemm
()
Ответ на: комментарий от acefsm

> вы хотите сказать, что ядро разрабатывают без отладки? )

Зависит от того, что вы имеете в виду под слоом "отладка"

> а зачем же тогда пользуются kdb?

Чтобы понять, где ж оно в панику ударилось, сцуко. 8))

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

kemm
()

qtcreator ещё не советовали, вроде? Тамошний вариант интеграции с gdb искаропки умеет некоторые плюсовые непотребства показывать в читаемом виде.

kemm
()
Ответ на: комментарий от Elverion

>А вообще, printf - лучший дебагер.

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

По теме: ddd

golodranez ★★★★
()
Ответ на: комментарий от anonymous

> насколько я понимаю, все Linux'овые отладчики основаны на gdb; и никакой новой функциональности не вносят.

Как раз потому, что никакой новой функциональности обычно и не надо. GDB умеет всё, но голый CLI порой слишком суров, поэтому к нему дорисовывают всякую гуйню. Но и GDB тоже не стоит на месте, недавно писали про какую-то жутко крутую новую фичу...

const86 ★★★★★
()
Ответ на: комментарий от kemm

>Дооо... То-то ещё ни один из платных аналогов по удобству не смог обогнать vim, а по фичастости хорошо если догнал...
аргументируйте, каких таких фич для работы нет в ide?
или vim уже научился управлять проектами?

>Доооо... В прошлый раз при попытках доказательства этого тезиса мы застряли на первой итерации, вроде? 8))

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

>Я разве спорю? Например, неплохая прибавка к заработку, наверное, рекламировать сликеди на лоре... 8))

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

>Я таки делаю это из любви к искусству. А вы таки хотите меня переманить? Таки я жду ваших предложений! 8))

вы уже не излечимы, а может и я ;-)

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

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

acefsm
()
Ответ на: комментарий от mono

>vc++ заруливает линуксовые IDE легко и красиво.

Только на доведение его до ума Микрософту понадобилось лет десять. Проблема тут только в С++.

Absurd ★★★
()
Ответ на: комментарий от const86

> Но и GDB тоже не стоит на месте, недавно писали про какую-то жутко крутую новую фичу...

Ты про Archer или ещё что-то интересное появилось?

kemm
()
Ответ на: комментарий от acefsm

> аргументируйте, каких таких фич для работы нет в ide?

Да как в том прекрасном анекдоте: "emacs -- прекрасная ОС, вот ему бы ещё нормальный редактор..."

kemm
()
Ответ на: комментарий от xorik

> Я не Линус, чтобы с первого раза писать идеально :)

Учись!

Nastishka ★★★★★
()
Ответ на: комментарий от wfrr

> Не парься, то кто пишут без отладчика, пишут в основном только на форумах.

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

Nastishka ★★★★★
()
Ответ на: комментарий от mipt_student

> Последний релиз - полтора года назад. Впрочем, у полюбившегося топикстартеру Dev-C++ - в 2005-м :D

В случае с C::B надо не на релизы ориентироваться, а на ночные билды, которые происходят (или происходили) регулярно.

Amp ★★★
()
Ответ на: комментарий от wfrr

>Не парься, то кто пишут без отладчика, пишут в основном только на форумах.

Продолжай тешить себя, криворукий друх.

linuxfan
()
Ответ на: комментарий от acefsm

>> vim уже научился управлять проектами?

прошу раскрыть тему "управления проектами".

Тут от соседнего рабочего места пришел наброс, что "управление проектами" всего лишь добавление нового исходника в некое место, после чего проект опять сам собирается по F9 (ил чего там жмется в венде). И что обычно про "проекты" начинают вести речь люди неосилившие Makefile/cmake/autotools.

yax123 ★★★★★
()

Неслабый срач я спровоцировал :)
По сабжу: остановился на Nemiver, пока устраивает. Единственное, чего не хватает: окно inspect, которое всегда на виду, а не в модальном окне

xorik ★★★★★
() автор топика

> Под виндой пользовался вот этим - http://img8.imageshack.us/img8/8027/debugz.jpg

Как вы добились таких ужасных шрифтов в винде?

Судя по тому, что вам нравится Dev-C++, то Code::Blocks для вас вполне подходит. Но брать его лучше из репозитория и собирать самому, или на форуме брать готовый ночной билд.

> * Хоткеи для действий (step, step into)


Code::Blocks

> * Удобный просмотр переменных


Code::Blocks

> * Чтобы был не в составе тяжелой IDE


Code::Blocks

andreyu ★★★★★
()
Ответ на: комментарий от xorik

> По сабжу: остановился на Nemiver, пока устраивает

Но он привязан к гному :(

А вообще, лучший отладчик, с которым я работал - это totalview. Но он закрытый и дорогой. Для себя лично покупать его не выгодно.

andreyu ★★★★★
()
Ответ на: комментарий от acefsm

> вот здесь отображение stl коллекций в emacs

Pretty-printing появился недавно и к фронтенду в принципе отношения не
имеет, потому как реализован полностью на стороне GDB с помощью
Python. Наряду с безостановочной отладкой многопоточных приложений эта
фича будет среди главных новшеств релиза 7.0. Библиотеки могут
распространяться со своими расширениями на Python для GDB, которые
будут автоматически подхватываться при отладке соответствующих
программ. Отображение контейнеров STL — за счёт соответствующего кода
в libstdc++.

Sphinx ★★☆☆
()
Ответ на: комментарий от xorik

> >Как вы добились таких ужасных шрифтов в винде?
> Это двойной jpeg :)


А, ну тогда ладно. Я уже было подумал, что в винде все так плохо ;)

andreyu ★★★★★
()
Ответ на: комментарий от xorik

> А может есть какая-нибудь IDE легковестная с дебаггером?

Если в емаксе в инит скрипт добавить: (setq gdb-many-windows t gdb-use-separate-io-buffer t) то будет весьма удобный дебаггер

kim-roader ★★
()
Ответ на: комментарий от Nastishka

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

wfrr ★★☆
()
Ответ на: комментарий от yax123

>прошу раскрыть тему "управления проектами".

>Тут от соседнего рабочего места пришел наброс, что "управление проектами" всего лишь добавление нового исходника в некое место, после чего проект опять сам собирается по F9 (ил чего там жмется в венде). И что обычно про "проекты" начинают вести речь люди неосилившие Makefile/cmake/autotools.


мне просто лень каждый раз править настройки в makefile
мне лень его создавать
как раз для этого и сделаны средства для генерации этих же makefile'ов
и cmake это одно из решений для кроссплатформенной генерации сборочных файлов под конкретную платформу
система управления проектами как раз уровень выше чем cmake, короче простой gui с возможность добавлять/удалять файлы, кофигурации для файлов/проектов/[окружения проектов](solution)

или не доходчиво объяснил?

acefsm
()
Ответ на: комментарий от kemm

>Да как в том прекрасном анекдоте: "emacs -- прекрасная ОС, вот ему бы ещё нормальный редактор..."

как редактор emacs хорош, но пока что не более
теже самые автоподолнения, ну нет их в нормальном виде
отладчик нормальный только сейчас и то в бете сделан gdb-mi

acefsm
()
Ответ на: комментарий от acefsm

а еще разруливание зависимостей, тестирование, генерация документации, и еженощьные бздениясборки

wfrr ★★☆
()
Ответ на: комментарий от Sphinx

да видел, клево, не спорю
но это совсем недавно сделано

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

acefsm
()
Ответ на: комментарий от wfrr

ну разруливание зависимостей как лежит на подобных makefile'ах и scons'ах

ночные сборки и тестирование например делали на python + cruise control
генерация доков - doxygen конечно же

acefsm
()
Ответ на: комментарий от Nastishka

при начальной разработке программы это правильный подход
но когда вы приходите в проект и вам достается около полумиллиона строк кода на C++, то так уже не получится без хорошей навигации по коду

или вы будете таблицы трассировки рисовать на бумажке? ;-)

acefsm
()
Ответ на: комментарий от wfrr

ну вообще я не встречал все что вы перечислили в одном комплекте
киньте ссылок на это чудо творение применительно к С++

acefsm
()
Ответ на: комментарий от wfrr

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

wfrr ★★☆
()
Ответ на: комментарий от lester

Вот еще ссылка на форум: http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=8249 И до сих пор VA не умеет различать перегруженные функции, даже встроенные в студию средства лучше работают. Так что о полноценной поддержки C++ на уровне compiler front end даже речи не идет.

kamre ★★★
()
Ответ на: комментарий от kamre

>Так что о полноценной поддержки C++ на уровне compiler front end даже речи не идет.

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

linuxfan
()
Ответ на: комментарий от kamre

собственно чем мне и нравится slickedit тем, что у него самый продвинутый intellisence который я видел, ну и навигация по коду у него выше всех, visual assist даже рядом не стоял

acefsm
()
Ответ на: комментарий от linuxfan

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

Ситуация с Visual Assist говорит о том, что они просто не осилили написать хороший парсер для C++. Ведь прероцессор/компилятор собирают проект.

В Xrefactory используется С++ front end от EDG, который ряд компиляторов использует. Поэтому в нем очень хороший парсер, намного лучше чем в VA.

kamre ★★★
()
Ответ на: комментарий от const86

>недавно писали про какую-то жутко крутую новую фичу...

Блин, прочитал как "про какую-то жутко кривую новую фичу" - задумался :)

MYMUR ★★★★
()
Ответ на: комментарий от acefsm

> в slickedit

Слушай, ты правда запарил. Можешь хоть один пост написать без слова slickedit? Я в упор не вижу, зачем новичку платить 300 баксов за это чудо. Его что, сразу в проект на полмиллиона строк кто то закинет? Учиться надо с vim, make и gdb в зубах. И так уж наплодили "программистов", которые даже скомпилировать своё поделие не умеют.

anonymous
()
Ответ на: комментарий от anonymous

слушай а ты реально запарил с vim, make, gdb в своих зубах

это тоже самое, что человека никогда не программирующего пустить за С++

я не видел ни одного реального аргумента в пользу vim, gdb, make, кроме конечно их бесплатности

acefsm
()
Ответ на: комментарий от acefsm

vim — привычный текстовый редактор с привычными хоткеями, с хорошо настраиваемой подсветкой синтаксиса, с большим количеством регистров, с поддержкой плагинов, с поддержкой макросов. (Почти) всё, что нужно текстовому редактору, там есть.

Написание кода — редактирование текста, значит, хороший текстовый редактор — необходим.

gdb — высокая кроссплатформенность, большое количество поддерживаемых языков. (что позволяет писать разные части программы на разных языках, выбирая языки по удобству/эффективности, а не из-за ограничеснности инструментария).

gdb — развитый отладчик. конечно, охватить его весь в одном посте нельзя. Возможность продвижения к вперёд, так и назад вкупе с развитой командой break и с командой commands —мне нравятся эти фичи.

Отладчик gdb имеет ряд фич, направленных на максимальную автоматизацию процесса отладки. Когда пользователю не нужно постоянно жать кнопочку next или step in и как там эти кнопочки называются.

anarquista ★★★★★
()
Ответ на: комментарий от anarquista

да блин вы, что все читаете между слов, что ли?

я говорил про выше уровень, slickedit,qtcreator и прочии тоже используют gdb и что? только в них не надо тратить время свое на настройку всякой ерунды

>gdb — развитый отладчик. конечно, охватить его весь в одном посте нельзя. Возможность продвижения к вперёд, так и назад вкупе с развитой командой break и с командой commands —мне нравятся эти фичи.

он нифига еще не развитый, только только научился показывать структуры stl и возможность задавать правила отображения своих структур

>Отладчик gdb имеет ряд фич, направленных на максимальную автоматизацию процесса отладки. Когда пользователю не нужно постоянно жать кнопочку next или step in и как там эти кнопочки называются.


да в нормальных ide никто никогда на кнопочки не жмет и не жал, все на хоткеях

>Написание кода — редактирование текста, значит, хороший текстовый редактор — необходим.

ну хоть редактирование есть, уже хорошо

acefsm
()
Ответ на: комментарий от acefsm

> да в нормальных ide никто никогда на кнопочки не жмет и не жал, все на хоткеях

хоткей это не кнопочка? На него жать не надо? Да даже если бы и не надо было бы жать, всего пришлось бы отвлекаться на телепатию.

anarquista ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.