Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
Но вопросов все равно много осталось:
1. точки останова (breakpoints) — поставить их легко C-x SPC, только как их визуально
наблюдать? (виден только треугольник текущего позиции выполнения)
2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение
переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные,
с изменяющимися значениями по ходу отладки, короче — watch?
К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>с изменяющимися значениями по ходу отладки, короче — watch?
display var
?
Re[2]: emacs, отладка
От:
Аноним
Дата:
09.11.05 07:07
Оценка:
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, L_user, Вы писали:
L_>>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>>с изменяющимися значениями по ходу отладки, короче — watch?
K>display var K>?
спасиб, display пропустил
А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть?
Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
Здравствуйте, Аноним, Вы писали:
А>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Аноним, Вы писали:
А>>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова?
K>Иметия не поняю. 8)) Я vim'ом пользуюсь.
ну хорошо, отладчиком-то все равно пользуетесь (ddd или чистый gdb?);
конкретная ситуация — обычно, ища очередную ошибку, в отладчике прогоняю прогамму
до определенного места с помощью continue (типа F5), next (типа F10), step (типа F11);
затем в редакторе "добираюсь" до нужной переменной (структуры!) и жму Shift+F9 (watch),
чтобы просмотреть значение(значения членов структуры);
можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
далее, если просматриваемая структура имеет вложенные структуры/указатели на структуры,
как можно "развернуть" их и посмотреть значения (конечно этот процесс может происходить по-другому, но главная цель,- как можно меньше нажать комбинаций клавиш клавиатуры/мышы)?
Здравствуйте, L_user, Вы писали:
А>>>А как же насчет точек останова? Мириться с тем, что можно по info breakpoints их посмотреть? А>>>Кстати, а есть ли команда в emacs, указыв номер breakpoint'а которой, перескакиваем в исходник/линию этой точки останова? K>>Иметия не поняю. 8)) Я vim'ом пользуюсь.
L_>ну хорошо, отладчиком-то все равно пользуетесь (ddd или чистый gdb?); L_>конкретная ситуация — обычно, ища очередную ошибку, в отладчике прогоняю прогамму L_>до определенного места с помощью continue (типа F5), next (типа F10), step (типа F11); L_>затем в редакторе "добираюсь" до нужной переменной (структуры!) и жму Shift+F9 (watch), L_>чтобы просмотреть значение(значения членов структуры);
L_>можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
Ну откуда я знаю, что там emacs умеет? Откуда gdb узнает, куда ему смотреть, если даже название ему не сказали? 8))
tab-completion не помогает? display, как я уже говорил, если постоянно в переменную смотреть нужно. tracepoints, watch порой тоже сильно помогают.
L_>далее, если просматриваемая структура имеет вложенные структуры/указатели на структуры, L_>как можно "развернуть" их и посмотреть значения (конечно этот процесс может происходить по-другому, но главная цель,- как можно меньше нажать комбинаций клавиш клавиатуры/мышы)?
gdb, слава богу, понимает сишный синтаксис.
p *pointer_to_struct
p *(pointer_to_struct->pointer_to_another_struct)
Более того, можно и функцию какую-нибудь позвать. 8))
Re[6]: просто отладка
От:
Аноним
Дата:
09.11.05 14:55
Оценка:
Здравствуйте, Kemm, Вы писали:
L_>>можно ли также в gdb/ddd — не набирая название переменной узнать ее содержимое
K> ... Откуда gdb узнает, куда ему смотреть, если даже название ему не сказали? 8)) K>tab-completion не помогает? display, как я уже говорил, если постоянно в переменную смотреть нужно. tracepoints, watch порой тоже сильно помогают.
ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь
(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать,
чтоб получить тот же результат)
Здравствуйте, Аноним, Вы писали:
А>ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь А>(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать, А>чтоб получить тот же результат)
Нафиг-нафиг. Производительность труда мерять в нажатиях клавиш, мягко говоря, странно. Да и не настолько часто приходится отладчиком пользоваться (если он необходим каждый день, да не по разу -- это что-то в консерватории менять надо, имхо).
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Аноним, Вы писали:
А>>ну так это плохо; вот тут и нужна интеграция с редактором, согласитесь А>>(в случае с gdb получаем меньшую производительность труда,- больше клавиш надо нажать, А>>чтоб получить тот же результат)
K>Нафиг-нафиг. Производительность труда мерять в нажатиях клавиш, мягко говоря, странно. Да и не настолько часто приходится отладчиком пользоваться (если он необходим каждый день, да не по разу -- это что-то в консерватории менять надо, имхо).
вы так уверены? Посмотрите на большие проекты, к примеру Open Source; а точнее на их Bugzill'ы — там кол-во ошибок исчисляется сотнями и тысячами; искать подобные ошибки
(первая задача maintainer'ов) порой приходится по всему коду, и именно с отладчиком;
на нахождение одной такой может уходить, как и пара минут, так и более 2 часов.
Естественно, что во втором случае на производительность сильно повлияет то, что приходится
нажимать больше клавиш, чем это требуется _логически_.
С проприетарным ПО дело обстоит точно также, ну или почти также (не хочу флэймить по этому
поводу)
Конечно, может быть вы пишете ПО как-то по-другому; но мы ведь не на "солнышке" живем,
и в большинстве своем оно преобладает в виде тех же браузеров (IE, Firefox) и офисов.
Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%;
а если иначе, то надо что-то менять?
Здравствуйте, L_user, Вы писали:
L_>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>а если иначе, то надо что-то менять?
Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
Здравствуйте, Глеб Алексеев, Вы писали:
L_>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>а если иначе, то надо что-то менять? ГА>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
И это в том числе. А так же:
1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами.
2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев.
Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8))
Re: emacs, отладка
От:
Аноним
Дата:
10.11.05 15:52
Оценка:
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Хммм. Похоже Основная ваша проблема в том, что та модель разработки (которую вы выбрали по средством выбора инструментария) в корне отличается от той к которой вы привыкли работая с VS. Не знаю причин по которым вы выбирали только из emacs и vim, но я бы предложил вам весьма достойную альтернативу, которая, к тому же, очень схожа (по модели разработки) с VS. Это eclipse + CDT (www.eclipse.org). Очень мощная и приятная IDE во многом превосходящая VS2003 (с VS2005 еще не работал сравнить не могу). Так что очень рекомендую.
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, Глеб Алексеев, Вы писали:
L_>>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>>а если иначе, то надо что-то менять? ГА>>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик.
Я не против того, чтобы отладка была в таком виде, в каком вы описали, т.е. юнит-тесты,
...
Но! Это не причина для того, чтобы не улучшать инструментарий для отладки. Сколько не
избегай ее (а также отсутствия юнит-тестов и т.д.), все равно настанет такой момент, что
сложный баг потребует этой самой отладки в "N-ое кол-во времени", и я хочу быть готовым к таким моментам (не дай бог им наступать, но все равно наступает), с самой эффективной
комбинацией из отладчика, редактора, и вообще всем чем можно.
Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Еще пример? Пожалуйста,- и самый, что ни на есть, юниксовый; до сих пор в отладчике gdb
(версия 6.3) не исправлена мерзкая ошибка с установкой точек останова (ошибка gdb/1091)
в конструкторах и деструкторах ("ставишь в конструктор break, а не работает, пролетает мимо "); Так вот, нашелся хороший человек,- http://people.freenet.de/BalaGi/, который
сделал patch, исправляющий ее (см. там же). Ему для этого потребовался целый день (он
не мэйнтэйнер, а ошибка-то его видно достала); догадайтесь, сколько времени из этого
он провел в отладчике?
K>И это в том числе. А так же: K>1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами.
подобный инструмент, конечно, очень помогает; но не избавляет от отладки
K>2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев.
даже с how to repeat в проекте размером с, например, Firefox искать ошибку очень долго
отладчик "при чем" более 50%, если не 90%
K>Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8))
замечаете,- разная у нас статистика; может у вас проект(ы) слишком специализированные
(это к вопросу,- "а не на солнышке ли вы живете?")
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, L_user, Вы писали:
L_>>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
А>Хммм. Похоже Основная ваша проблема в том, что та модель разработки (которую вы выбрали по средством выбора инструментария) в корне отличается от той к которой вы привыкли работая с VS. Не знаю причин по которым вы выбирали только из emacs и vim, но я бы предложил вам весьма достойную альтернативу, которая, к тому же, очень схожа (по модели разработки) с VS. Это eclipse + CDT (www.eclipse.org). Очень мощная и приятная IDE во многом превосходящая VS2003 (с VS2005 еще не работал сравнить не могу). Так что очень рекомендую.
Не, я, конечно, и на другие IDE смотрел и смотрю сейчас. Просто хочу узнать всю
"магическую силу" еmacs/vim.
Вот список того, что я уже перебрал-попробовал (у каждой есть свои плюсы/минусы, это не blacklist):
Anjuta
Kdevelop
vim+ddd/gdb
Eclipse+CDT
emacs или xemacs
C-Forge
На очереди пока двое — SlickEdit и Code::Blocks
Народ, если чего еще есть на Linux-платформе,- черкните в этот тред,
буду сильно благодарен
L_>
L_>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, L_user, Вы писали:
L_>Не, я, конечно, и на другие IDE смотрел и смотрю сейчас. Просто хочу узнать всю L_>"магическую силу" еmacs/vim.
L_>Вот список того, что я уже перебрал-попробовал (у каждой есть свои плюсы/минусы, это не blacklist):
L_>Anjuta L_>Kdevelop L_>vim+ddd/gdb L_>Eclipse+CDT L_>emacs или xemacs L_>C-Forge
L_>На очереди пока двое — SlickEdit и Code::Blocks
L_>Народ, если чего еще есть на Linux-платформе,- черкните в этот тред, L_>буду сильно благодарен
И в качестве совета (если позволено будет) -- попробуй вместо отладчика использовать отладочные печати и логирование. Очень сильно меняет мышление. А в многопоточных или многопроцессовых/распределенных приложениях помощь от отладчика стремиться к нулю.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, L_user, Вы писали:
L_>>>>Итак, вы все же считаете, что отладка не должна занимать много времени, ну скажем 10%; L_>>>>а если иначе, то надо что-то менять? ГА>>>Позволю себе встрять в беседу без приглашения. Мне кажется, Kemm имел в виду, что отлаживать надо без отладчика, т.е. в первую очередь — юнит-тесты, во вторую — ассерты, в третью — трассировка, в четвертую — отладчик. L_>Я не против того, чтобы отладка была в таком виде, в каком вы описали, т.е. юнит-тесты, L_>... L_>Но! Это не причина для того, чтобы не улучшать инструментарий для отладки. Сколько не L_>избегай ее (а также отсутствия юнит-тестов и т.д.), все равно настанет такой момент, что L_>сложный баг потребует этой самой отладки в "N-ое кол-во времени", и я хочу быть готовым к таким моментам (не дай бог им наступать, но все равно наступает), с самой эффективной L_>комбинацией из отладчика, редактора, и вообще всем чем можно.
L_> L_>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
Я предпочитаю писать не "изящно". 8)) Уж лучше пусть кода будет в два раза больше, чем потом изыскивать какой-нибудь особо злое^Wхитрый баг. Причем повторить его (чтобы можно было тот самый отладчик заиспользовать) получается далеко не всегда.
L_>Еще пример? Пожалуйста,- и самый, что ни на есть, юниксовый; до сих пор в отладчике gdb L_>(версия 6.3) не исправлена мерзкая ошибка с установкой точек останова (ошибка gdb/1091) L_>в конструкторах и деструкторах ("ставишь в конструктор break, а не работает, пролетает мимо "); Так вот, нашелся хороший человек,- http://people.freenet.de/BalaGi/, который L_>сделал patch, исправляющий ее (см. там же). Ему для этого потребовался целый день (он L_>не мэйнтэйнер, а ошибка-то его видно достала); догадайтесь, сколько времени из этого L_>он провел в отладчике?
Без понятия. У нас plain-C. 8))) Мне больше не нравится косяк в gdb, когда он как-то странно по шагам проходит. 100% воспроизведения добиться не удалось... 8(( Но анноит сильно.
K>>И это в том числе. А так же: K>>1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами. L_>подобный инструмент, конечно, очень помогает; но не избавляет от отладки
Не избавляет. Это в дополнение, очевидно. Зато позволяет отсечь кучу моментов, против которых отладка не поможет.
K>>2) bug report должен идти вместе с пунктом How To Repeat. Опять отладчик не при чем более чем в 90% случаев. L_>даже с how to repeat в проекте размером с, например, Firefox искать ошибку очень долго L_>отладчик "при чем" более 50%, если не 90%
K>>Итого отладчик нужен редко. Причем в таких случаях, что и он-то особо не помогает обычно. Как показывает практика, именно тогда выявляются самые тупые ошибки. 8)) L_>замечаете,- разная у нас статистика; может у вас проект(ы) слишком специализированные L_>(это к вопросу,- "а не на солнышке ли вы живете?")
Возможно. Только вот если 10% времени в отладчике -- это все равно перебор. Еще вариант: я привык пользоваться gdb без привязки к редактору.
По делу: попробуй kdevelop (вдруг понравится, мне не пошел ни под каким соусом), vim с привязкой к gdb (скрипт на vim.sf.net)
Здравствуйте, L_user, Вы писали:
L_>Собственно, именно из-за этого я выбрал emacs, а не vim — встроенный отладчик (gud)
L_>Но вопросов все равно много осталось: L_> 1. точки останова (breakpoints) — поставить их легко C-x SPC, только как их визуально L_>наблюдать? (виден только треугольник текущего позиции выполнения) L_> 2. просмотр переменных,- в принципе все ясно,- пишем "p var" в gud и видим значение L_>переменной var; но хотелось бы иметь окошко, в котором постоянно "лежали" бы переменные, L_>с изменяющимися значениями по ходу отладки, короче — watch?
L_>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Начиная с версии 21.4 у емакса есть нормальный графический интерфейс к gdb, там это есть.
Вот тут можно посмотреть: http://www.linuxjournal.com/article/7876
Модуль называется gdb-ui.el
Здравствуйте, z00n, Вы писали:
L_>>К самому редактору претензий нет, но перелезая с VS (чего скрывать уж ), хочется не потерять в качестве разработки на C++
Z>Начиная с версии 21.4 у емакса есть нормальный графический интерфейс к gdb, там это есть. Z>Вот тут можно посмотреть: http://www.linuxjournal.com/article/7876 Z>Модуль называется gdb-ui.el
L_>>
L_>>Скажите, что такое редко случается? Такие редко, но все равно, 10 часов — лучше чем 20 часов или ничего (в смысле, вообще не найти ошибку).
E>Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
Вы никогда не делаете ошибок? Или, вы всегда все делаете правильно с первого раза?
Я думаю, что после этой ошибки были сделаны соответствующие выводы; а до этого просто все работало, и никто даже
и предполагать не мого, что возможны проблемы. Уверен, что там кроме этой ошибки есть еще и другие (это нормальная
ситуация в софтверной индустрии), просто еще не "стрельнули"; и той команде их придется отловить, как отловили
эту. ИМХО.
Здравствуйте, Kemm, Вы писали:
L_>>Еще пример? Пожалуйста,- и самый, что ни на есть, юниксовый; до сих пор в отладчике gdb L_>>(версия 6.3) не исправлена мерзкая ошибка с установкой точек останова (ошибка gdb/1091) L_>>в конструкторах и деструкторах ("ставишь в конструктор break, а не работает, пролетает мимо "); Так вот, нашелся хороший человек,- http://people.freenet.de/BalaGi/, который L_>>сделал patch, исправляющий ее (см. там же). Ему для этого потребовался целый день (он L_>>не мэйнтэйнер, а ошибка-то его видно достала); догадайтесь, сколько времени из этого L_>>он провел в отладчике?
K>Без понятия. У нас plain-C. 8))) Мне больше не нравится косяк в gdb, когда он как-то странно по шагам проходит. 100% воспроизведения добиться не удалось... 8(( Но анноит сильно.
ну так,- прямой путь ловить ошибку-отлаживать gdb ; не привыкать же к глюкам, как это приходиться делать Windows-пользователям, исходники-то есть, правильно?
K>>>И это в том числе. А так же: K>>>1) valgrind. Мы же о юниксах говорим? И не о ядре? Тогда на линуксе или фре должно работать. Тогда без этой штуки вообще неясно что делать с memory leak'ами. L_>>подобный инструмент, конечно, очень помогает; но не избавляет от отладки
K>Не избавляет. Это в дополнение, очевидно. Зато позволяет отсечь кучу моментов, против которых отладка не поможет.
Да не против я Valgrind'а (а также Purify, BoundsChecker и т.д.); я против того, чтоб были узкие звенья в "цепи
разработки", коим, похоже, является отладка в Unix посредством одного gdb
K>По делу: попробуй kdevelop (вдруг понравится, мне не пошел ни под каким соусом), vim с привязкой к gdb (скрипт на vim.sf.net)
eao197 wrote:
> И в качестве совета (если позволено будет) -- попробуй вместо > отладчика использовать отладочные печати и логирование. Очень сильно > меняет мышление. А в многопоточных или многопроцессовых/распределенных > приложениях помощь от отладчика стремиться к нулю.
Если в этом отладчике нет потоковых меток — тогда он будет незаменим
Здравствуйте, L_user, Вы писали:
K>>Без понятия. У нас plain-C. 8))) Мне больше не нравится косяк в gdb, когда он как-то странно по шагам проходит. 100% воспроизведения добиться не удалось... 8(( Но анноит сильно. L_>ну так,- прямой путь ловить ошибку-отлаживать gdb ; не привыкать же к глюкам, как это приходиться делать Windows-пользователям, исходники-то есть, правильно?
Я выделил. Без How-To-Repeat дебажить можно долго и со вкусом. Только без толку. 8)) Причем замечено проявление только на FC2 и соляре 8/9. Пока не до того.
K>>Не избавляет. Это в дополнение, очевидно. Зато позволяет отсечь кучу моментов, против которых отладка не поможет. L_>Да не против я Valgrind'а (а также Purify, BoundsChecker и т.д.); я против того, чтоб были узкие звенья в "цепи L_>разработки", коим, похоже, является отладка в Unix посредством одного gdb
ХЗ. Я, честно говоря, не писал сложный _пользовательских_ приложений. А так наш софт при включенном полном дебаге валит достаточно сообщений, чтобы можно было найти баг без gdb. Другое дело -- кору посмотреть, если вдруг нарисовалась.
K>>По делу: попробуй kdevelop (вдруг понравится, мне не пошел ни под каким соусом), vim с привязкой к gdb (скрипт на vim.sf.net) L_> L_>см. http://www.rsdn.ru/Forum/NewMsg.aspx?gid=22
Хм. И что в форме для нового сообщения я должен увидеть? 8))
Здравствуйте, Kemm, Вы писали:
K>Здравствуйте, L_user, Вы писали:
K>>>Без понятия. У нас plain-C. 8))) Мне больше не нравится косяк в gdb, когда он как-то странно по шагам проходит. 100% воспроизведения добиться не удалось... 8(( Но анноит сильно. L_>>ну так,- прямой путь ловить ошибку-отлаживать gdb ; не привыкать же к глюкам, как это приходиться делать Windows-пользователям, исходники-то есть, правильно?
K>Я выделил. Без How-To-Repeat дебажить можно долго и со вкусом. Только без толку. 8)) Причем замечено проявление только на FC2 и соляре 8/9. Пока не до того.
ну ладно, я же не настаиваю,
K>>>По делу: попробуй kdevelop (вдруг понравится, мне не пошел ни под каким соусом), vim с привязкой к gdb (скрипт на vim.sf.net) L_>> L_>>см. http://www.rsdn.ru/Forum/NewMsg.aspx?gid=22
K>Хм. И что в форме для нового сообщения я должен увидеть? 8))
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, L_user, Вы писали:
L_>>Anjuta L_>>Kdevelop L_>>vim+ddd/gdb L_>>Eclipse+CDT L_>>emacs или xemacs L_>>C-Forge
L_>>На очереди пока двое — SlickEdit и Code::Blocks
L_>>Народ, если чего еще есть на Linux-платформе,- черкните в этот тред, L_>>буду сильно благодарен
E>Еще вот сюда загляни: 10 Reasons to Dump Your [Java] IDE
Видел я эту статью. Всей правды она не сказала, однобокая она.
Хотя бы потому, что обучить новичка (вчерашний студент) и нормально втянуть его в серьезный проект — это очень долго и стоит много денег. Вот тут-то IDE и помогает (и проект соберет, и в навигации поможет, и все это без излишних технических деталей). А со временем он разберется, если голова на плечах есть; это ведь ему самому нужно,
а не огранизации, где он работает, правильно?
Кстати, а чем Emacs не IDE (интегрированная среда разработки)? Все признаки есть: и окно компиляции, и окно
отладки, и speedbar для навигации, и привязка к CVS/RCS/... . И все это в включено в базовый пакет, а не внешние плугины.
Так что автор даже с терминами не разобрался ; так, на троечку ...
E>И в качестве совета (если позволено будет) -- попробуй вместо отладчика использовать отладочные печати и логирование. Очень сильно меняет мышление. А в многопоточных или многопроцессовых/распределенных приложениях помощь от отладчика стремиться к нулю.
Не все ПО исчерпывается многопоточными/многопроцессорными программами. А если уж очень нужно добавить такой код
в проект, то адекватно организовать процесс след. образом:
— выделить пару-тройку знающих человек для разработки такого кода;
— всем остальным ограничить доступ к правке такого кода;
И тогда отладчик останется полезным инструментом (конечно, при условии, что те трое ответственно подходят
к своей работе).
Здравствуйте, L_user, Вы писали:
E>>Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
L_>Вы никогда не делаете ошибок? Или, вы всегда все делаете правильно с первого раза?
Почему же? Делаю и ошибки, и серьезные промахи при проектировании и пр. и пр.
L_>Я думаю, что после этой ошибки были сделаны соответствующие выводы; а до этого просто все работало, и никто даже L_>и предполагать не мого, что возможны проблемы.
А вот здесь я не согласен. Использование нетривиальных конструкций языка (например, шаблон для перегрузки оператора запятая), да еще без опыта разработки многопоточных приложений -- это, имхо, явное напрашивание на неприятности. Пословица есть хорошая: "Не зная броду -- не суйся в воду".
L_> Уверен, что там кроме этой ошибки есть еще и другие (это нормальная L_>ситуация в софтверной индустрии), просто еще не "стрельнули"; и той команде их придется отловить, как отловили L_>эту. ИМХО.
Применение простых конструкций и решений серьезно уменьшают количество потенциальных и реальных ошибок в программе. И не требуют затем сложных инструментов для поиска ошибок. Вот, например, сколько тебе нужно времени, чтобы разобраться, как работает и как применять приведенный в Re[2]: sequence points
код (классы shared_resource, out_argument и lock, а так же функции access и swap)? А теперь сравни это с классом ACE_Guard:
/**
* @class ACE_Guard
*
* @brief This data structure is meant to be used within a method or
* function... It performs automatic aquisition and release of
* a parameterized synchronization object <ACE_LOCK>.
*
* The <ACE_LOCK> class given as an actual parameter must provide at
* the very least the <acquire>, <tryacquire>, <release>, and
* <remove> methods.
*/template <class ACE_LOCK>
class ACE_Guard
{
public:
// = Initialization and termination methods.
ACE_Guard (ACE_LOCK &l);
/// Implicitly and automatically acquire (or try to acquire) the
/// lock. If <block> is non-0 then <acquire> the <ACE_LOCK>, else
/// <tryacquire> it.
ACE_Guard (ACE_LOCK &l, int block);
/// Initialise the guard without implicitly acquiring the lock. The
/// <become_owner> parameter indicates whether the guard should release
/// the lock implicitly on destruction. The <block> parameter is
/// ignored and is used here to disambiguate with the preceding
/// constructor.
ACE_Guard (ACE_LOCK &l, int block, int become_owner);
/// Implicitly release the lock.
~ACE_Guard (void);
// = Lock accessors.
/// Explicitly acquire the lock.int acquire (void);
/// Conditionally acquire the lock (i.e., won't block).int tryacquire (void);
/// Explicitly release the lock, but only if it is held!int release (void);
/// Relinquish ownership of the lock so that it is not released
/// implicitly in the destructor.void disown (void);
// = Utility methods.
/// 1 if locked, 0 if couldn't acquire the lock
/// (errno will contain the reason for this).int locked (void) const;
/// Explicitly remove the lock.int remove (void);
/// Dump the state of an object.void dump (void) const;
// ACE_ALLOC_HOOK_DECLARE;
// Declare the dynamic allocation hooks.protected:
/// Helper, meant for subclass only.
ACE_Guard (ACE_LOCK *lock): lock_ (lock) {}
/// Pointer to the ACE_LOCK we're guarding.
ACE_LOCK *lock_;
/// Keeps track of whether we acquired the lock or failed.int owner_;
private:
// = Prevent assignment and initialization.
ACE_UNIMPLEMENTED_FUNC (void operator= (const ACE_Guard<ACE_LOCK> &))
ACE_UNIMPLEMENTED_FUNC (ACE_Guard (const ACE_Guard<ACE_LOCK> &))
};
В общем, программирование -- это борьба со сложностью, а не порождение оной.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
L_>Видел я эту статью. Всей правды она не сказала, однобокая она.
Да я не про стаью, а про обсуждение Забыл уточнить.
L_>Кстати, а чем Emacs не IDE (интегрированная среда разработки)? Все признаки есть: и окно компиляции, и окно L_>отладки, и speedbar для навигации, и привязка к CVS/RCS/... . И все это в включено в базовый пакет, а не внешние плугины.
Кстати, а нафига IDE вообще нужна? А то я никогда не пользовался, не знаю, может это-то хорошее?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
L_>>Я думаю, что после этой ошибки были сделаны соответствующие выводы; а до этого просто все работало, и никто даже L_>>и предполагать не мого, что возможны проблемы. E>А вот здесь я не согласен. Использование нетривиальных конструкций языка (например, шаблон для перегрузки оператора запятая), да еще без опыта разработки многопоточных приложений -- это, имхо, явное напрашивание на неприятности. Пословица есть хорошая: "Не зная броду -- не суйся в воду".
Мне такое, честно говоря, больше анекдот напоминает:
-- Доктор, когда я делаю вот так (изображает что-то из йоги), у меня жутко болит спина.
-- А вы так не делайте!
Здравствуйте, eao197, Вы писали:
E>>Если бы там в крутизну в песочницу не игрались, и делали нормальные thread-safe классы вместо "умных" оберток для thread-unsafe классов, то им и не пришлось бы ничего отлаживать. ИМХО.
Как раз там в крутизну не игрались. Даже template как в ACE_Guard не использовали. А явно повторили его код в каждом class lock_resource{…}; Для каждого типа ресурса.
Приведённые мной обёртки всего лишь обобщили и защитили их способ блокировок. И никак не провоцировали, а наоборот исправляли ошибку.
L_>Я думаю, что после этой ошибки были сделаны соответствующие выводы; а до этого просто все работало, и никто даже и предполагать не мого, что возможны проблемы. E>А вот здесь я не согласен. Использование нетривиальных конструкций языка (например, шаблон для перегрузки оператора запятая), да еще без опыта разработки многопоточных приложений -- это, имхо, явное напрашивание на неприятности. Пословица есть хорошая: "Не зная броду -- не суйся в воду".
Это тоже неверно шаблон для перегрузки оператора запятая был введён специально для решения поставленной задачи. ПРИВЕСТИ К ТРУДНО ОБНАРУЖИМЫМ ОШИБКАМ ПРИЛОЖЕНИЯ. С чем блестяще справился. И наверно доставил массу радости своему создателю. (чего не скажешь обо мне, но я решал противоположную задачу).
Вы будете смеяться, но (несколько лет назад) это был именно мой первый практический опыт в многопоточном программировании.
E>> Применение простых конструкций и решений серьезно уменьшают количество потенциальных и реальных ошибок в программе. И не требуют затем сложных инструментов для поиска ошибок. Вот, например, сколько тебе нужно времени, чтобы разобраться, как работает и как применять приведенный в Re[2]: sequence points код (классы shared_resource, out_argument и lock, а так же функции access и swap)? А теперь сравни это с классом ACE_Guard:
Ну lock и ACE_Guard если не родные то двоюродные братья. А остальное связано с тем что я решал гораздо более сложный комплекс задач чем решает ACE_Guard. Например я ставил задачу запретить пользоваться разделяемым ресурсом без блокировок.
А о простоте и сложности я планирую написать в философии…
(виден только треугольник текущего позиции выполнения)
), хочется не потерять в качестве разработки на C++
