Здравствуйте, 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. Например я ставил задачу запретить пользоваться разделяемым ресурсом без блокировок.
А о простоте и сложности я планирую написать в философии…
; не привыкать же к глюкам, как это приходиться делать Windows-пользователям, исходники-то есть, правильно?
