А вообще мне эта тема напиминает то, что я слышал от одного приятеля-дельфака примерно 8-10 лет назад.
Он тоже волей судеб был вынужден переходить на Visual Studio с Delphi, и рассказывал, что VS — Г, а вот Delphi — действительно стандарт и вершина мысли в области посроения UI для сред разработки.
Претензии были абсолютно те же самые: "я привык так, а VS так не умеет".
Здравствуйте, jazzer, Вы писали:
C>>>В C++ в одном файле могут быть несколько классов. Как мне быстро найти, C>>>где определен данный класс? Еще часто очень удобно посмотреть какие у C>>>класса есть наследники и предки.
E>>doxygen мне в этом очень помогает.
J>а он отслеживает, какие файлы изменились, с тем, чтобы перепарсить только их? J>Или он каждый раз заново парсит всю тучу файлов проекта?
Нет, не отслеживает.
Но это не проблема по нескольким причинам.
Во-первых, doxygen работает весьма шустро.
Во-вторых, в нем есть возможность создавать т.н. tag-файлы (xml-файлы с результатами предыдущего разбора) и подключать их впоследствии. Поэтому большие проекты можно разбить на несколько tag-ов и перегенерировать только то, что изменялось (правда придется делать это вручную).
Ну и еще такой фактор -- doxygen описания, как правило нужны для тех фрагментов программы, которые давно разрабатывались. А в том, что я сейчас делаю, я и так нормально ориентируюсь.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Quintanar wrote:
>> C>Проблема в том, что сейчас есть де-факто стандарты на IDE. >> VS никоим местом не стандарт, даже де-факто.
C>Я не про VS говорю, а про общие принципы создания современных IDE. В C>частности, они подразумевают использование понятия "проектов",
А совместимость тоже наличествует? Или проекты — это все должны писать только
под VS или городить огород как в той-же ACE с кучей разных проектов под все
"правильные" IDE?
C>современные IDE предоставляют пользователю удобную навигацию по дереву C>проекта,
Что есть "удобная навигация"? Без мышки слабо навигироваться? Я вот ее не использую.
Мне не будет удобно в этой супер стандартной IDE. А вот в этой будет. http://www.xref-tech.com/xrefactory/images/emacs/browsing.png
C> tabbed MDI интерфейс,
C>удобные (и достаточно стандартные) меню.
Хмм. А зачем они? Меню? Опять 25. Говорят же, тут другие правила
и приемы. Ну не пользуют тут меню. Не нужны они. Все делается либо
через shortcut либо через команды (Выход ":q" в vi, "C-x C-c" в emacs, или
:%s/sss/sss/ в vi M-x replace-regex в emacs)
C>Так же, считается хорошим тоном иметь встроеный отладчик и некоторы C>интегрированые инструменты.
Опять же любовь прививаемая MS. Зачем сторониие тулзы? Большой MS позаботится о вас:
Outlook + MSIE + VS + VSDebugger + VSS + ... Жуть. И всякие Eclipse и прочие двигаются
туда же, лишь бы переманить юзверей с VS на свои продукты. А дабы не возникало
вопросов мы сделаем "удобный, интуитивный MDI tabbed mousdriven menu based lemming friendly interface"
Супер. Ума не приложу, как и каким боком можно было общаться с unix 10 лет и такое городить .
Неужели Вам не встречался ни разу ни один юниксоид и вы не видели насколько удобно
ему в этом окружении работать? Либо цифра сильно завшена либо работа сводилась к "залить файло по фтп".
ЗЫ: сорри если кому покажется что это переход на личности. Мне действительно интересно.
aka50 wrote:
> C>Я не про VS говорю, а про общие принципы создания современных IDE. В > C>частности, они подразумевают использование понятия "проектов", > А совместимость тоже наличествует? Или проекты — это все должны писать > только > под VS или городить огород как в той-же ACE с кучей разных проектов > под все > "правильные" IDE?
Нет, проекты несовместимы, к сожалению. Хотя их форматы часто весьма
похожи. Вот тот же ACE или Apache спокойно ложаться на разные форматы
проектных файлов, что свидетельствует о достаточно универсальности
понятия "проект".
> C>современные IDE предоставляют пользователю удобную навигацию по дереву > C>проекта, > Что есть "удобная навигация"? Без мышки слабо навигироваться?
Слабо, так как я не хочу запоминать ВСЕ клавиатурные сокращения. Я
предпочитаю раз в неделю ткнуть мышкой в какой нибудь редкоиспользуемый
пункт меню, а не рыться в доке в поисках его клавиатурного сокращения
или имя команды.
Для всех часто используемых операций, естественно, я использую
клавиатурные сокращения.
> Я вот ее не использую. > Мне не будет удобно в этой супер стандартной IDE. А вот в этой будет. > http://www.xref-tech.com/xrefactory/images/emacs/browsing.png
Про XRef я вроде уже сказал, что оно — рулез. И прикручивается она к
чему угодно, так как работает сервером.
> C> tabbed MDI интерфейс, > C>удобные (и достаточно стандартные) меню. > Хмм. А зачем они? Меню? Опять 25.
Для удобного просмотра всех доступных действий.
> Говорят же, тут другие правила > и приемы. Ну не пользуют тут меню. Не нужны они. Все делается либо > через shortcut либо через команды (Выход ":q" в vi, "C-x C-c" в emacs, или > :%s/sss/sss/ в vi M-x replace-regex в emacs)
Опять же — банальные команды редактирования через меню вызываются всего
несколько раз — чтобы запомнить их шорткаты. Меню нужны для сложных и
редких действий типа какого-нибудь "запустить в дебаггере с поддержкой
UML на машине в Африке через SSH поверх голубиной почты".
> C>Так же, считается хорошим тоном иметь встроеный отладчик и некоторы > C>интегрированые инструменты. > Опять же любовь прививаемая MS. Зачем сторониие тулзы?
Просто так. Например, прикрутить test coverage тулзу там, или профайлер.
Или в emacs'е есть уже все что нужно до конца времен?
> Большой MS позаботится о вас: > Outlook + MSIE + VS + VSDebugger + VSS + ... Жуть.
Outlook+MSIE к VS отношения имеют мало. Разве что MS используется в
качестве рендерера для HTML.
VS+VSDebugger — не имеет смысла разделять, но если так хочется, то можно
приделать к Студии даже gdb — для этого есть публичные и
документированые интерфейсы.
VSS работает поверх SCC-интерфейса, через который можно подключить к
Студии практически любую систему контроля версий. В частности: CVS,
Subversion, ClearCase, Perforce и даже RCS. К сожалению, до недавнего
времени документацию о SCC можно было получить только под NDA, хотя и
бесплатно (я сам его подписывал, кстати).
> И всякие Eclipse и прочие двигаются туда же, лишь бы переманить > юзверей с VS на свои продукты.
Нормальный процесс, я не говорю, что VS идеальна, но вот замены ей
что-то не видно.
> А дабы не возникало вопросов мы сделаем "удобный, интуитивный MDI > tabbed mousdriven menu based lemming friendly interface" > Супер. Ума не приложу, как и каким боком можно было общаться с unix 10 > лет и такое городить .
А что, все кто работает под *nix'ами обязаны любить Emacs/vim и
закрывать глаза на более удобные инструменты?
> Неужели Вам не встречался ни разу ни один юниксоид и вы не видели > насколько удобно > ему в этом окружении работать?
В том-то и дело, что видел как "удобно".
> Либо цифра сильно завшена либо работа сводилась к "залить файло по фтп".
Да, да. И больше ничего я не умею, только еще настраиваю Mysql через
phpMysqlAdmin (в перерывах между правкой ядерных модулей и апачевских
расширений).
Здравствуйте, Cyberax, Вы писали:
C>Нет, проекты несовместимы, к сожалению. Хотя их форматы часто весьма C>похожи. Вот тот же ACE или Apache спокойно ложаться на разные форматы C>проектных файлов, что свидетельствует о достаточно универсальности C>понятия "проект".
Понятие "проект" в данном случае это конь в вакууме... при чем сферический.
Особенно удобно продираться сквозь кучу файла типа .vsproj и Makefile.GNU.
А если разработчики либы не позаботились? Бум в свое IDE это руками пихать?
Я например в этом случае использую CMake. Ибо нету траблов с этими чудесами,
всегда можно NMake или make проект (проект как структуру каталогов и файлов
на диске) получить без отдельных головных болей.
>> C>современные IDE предоставляют пользователю удобную навигацию по дереву >> C>проекта, >> Что есть "удобная навигация"? Без мышки слабо навигироваться?
C>Слабо, так как я не хочу запоминать ВСЕ клавиатурные сокращения. Я C>предпочитаю раз в неделю ткнуть мышкой в какой нибудь редкоиспользуемый C>пункт меню, а не рыться в доке в поисках его клавиатурного сокращения C>или имя команды. C>Для всех часто используемых операций, естественно, я использую C>клавиатурные сокращения.
Опять же. Не надо ничего запоминать. На все есть всемогущий autocomplete.
(пример ниже где про ssh)
C>Про XRef я вроде уже сказал, что оно — рулез. И прикручивается она к C>чему угодно, так как работает сервером.
Я про нее вспоминаю применительно к тому, что этой штуки в купе с emacs
достаточно . А для С или С с классами достаточно и cedet.
>> C> tabbed MDI интерфейс, >> C>удобные (и достаточно стандартные) меню. >> Хмм. А зачем они? Меню? Опять 25.
C>Для удобного просмотра всех доступных действий.
Как я уже говорил C-h b спасет отца русской демократии.
C>Опять же — банальные команды редактирования через меню вызываются всего C>несколько раз — чтобы запомнить их шорткаты. Меню нужны для сложных и C>редких действий типа какого-нибудь "запустить в дебаггере с поддержкой C>UML на машине в Африке через SSH поверх голубиной почты".
Допустим у нас есть некий пакет debug-via-ssh. Тогда пути 2.
1. Если все правильно названо, то и имеет префикс dvs
M-x dvs-<TAB>*тут мы получим список возможных комманд*
M-x dvs-co<TAB> -> dvs-connect <ENTER>
Which command we will use? ssh debuguser@africa | golubinaja_pochta decode |
What we will debug via ssh? /u<TAB>/b<TAB>/su<TAB> -> /usr/bin/superproga
(после /u<TAB> может попросить ssh пароль если нету ключей)
открылось окно отладчика через ssh декодированный golubinaja_pochta туннель. Отлаживаемся.
Возражения на тему, а кто напишет чтобы все эти вопросы Where и What задавались,
отвечу вопросом: а кто напишет и нарисует формочки и предусмотрит все варианты
использования? Тут хоть пайпы прозрачно встраиваются.
>> C>Так же, считается хорошим тоном иметь встроеный отладчик и некоторы >> C>интегрированые инструменты. >> Опять же любовь прививаемая MS. Зачем сторониие тулзы?
C>Просто так. Например, прикрутить test coverage тулзу там, или профайлер. C>Или в emacs'е есть уже все что нужно до конца времен?
Как показал выше все это и так легко вкручивается. Никто не говорит, что
все есть в emacs. Разговор как раз об обратном, что на все есть сторонние тулзы
и не совсем обязательно даже встроенный дебагер. Как раз по Вашей логике надо
чтобы и "test coverage тулзу там, или профайлер" тоже были встроены в IDE.
C>VSS работает поверх SCC-интерфейса, через который можно подключить к C>Студии практически любую систему контроля версий. В частности: CVS, C>Subversion, ClearCase, Perforce и даже RCS. К сожалению, до недавнего C>времени документацию о SCC можно было получить только под NDA, хотя и C>бесплатно (я сам его подписывал, кстати).
Это я знаю... но он достаточно убогий (во всяком случае все что я видел
под VS для работы с subversion и cvs достаточно убого... особенно любов
MS на все lock ставить )
>> И всякие Eclipse и прочие двигаются туда же, лишь бы переманить >> юзверей с VS на свои продукты. C>Нормальный процесс, я не говорю, что VS идеальна, но вот замены ей C>что-то не видно.
Замены? А кто ее хочет заменить? Под вынь особенно?
>> А дабы не возникало вопросов мы сделаем "удобный, интуитивный MDI >> tabbed mousdriven menu based lemming friendly interface" >> Супер. Ума не приложу, как и каким боком можно было общаться с unix 10 >> лет и такое городить .
C>А что, все кто работает под *nix'ами обязаны любить Emacs/vim и C>закрывать глаза на более удобные инструменты?
Ну как минимум не надо делать громких заявлений на предмет стандартов
и удобства. Везде свои законы и стандарты.
>> Либо цифра сильно завшена либо работа сводилась к "залить файло по фтп".
C>Да, да. И больше ничего я не умею, только еще настраиваю Mysql через C>phpMysqlAdmin (в перерывах между правкой ядерных модулей и апачевских C>расширений).
Интересно в чем это делается? Особенно те 9 лет до появления интереса к
emacs/vi/...? Я догадываюсь что FAR + Ftp + ssh .
aka50 wrote:
> C>Нет, проекты несовместимы, к сожалению. Хотя их форматы часто весьма > C>похожи. Вот тот же ACE или Apache спокойно ложаться на разные форматы > C>проектных файлов, что свидетельствует о достаточно универсальности > C>понятия "проект". > Понятие "проект" в данном случае это конь в вакууме... при чем > сферический. > Особенно удобно продираться сквозь кучу файла типа .vsproj и Makefile.GNU.
Ну а что делать?
> А если разработчики либы не позаботились? Бум в свое IDE это руками > пихать?
Я так, собственно, и делаю. С Boost'ом, например.
> Я например в этом случае использую CMake. Ибо нету траблов с этими > чудесами, > всегда можно NMake или make проект (проект как структуру каталогов и > файлов > на диске) получить без отдельных головных болей.
Я давно ищу тулзу, которая сможет генерировать vcproj-файлы из некого
формального описания проекта _И_ еще переносить изменения из vcproj
обратно в описание проекта. Сейчас использую для этого самодельный xsl,
но он годится только для моего собственного layout'а каталогов в проекте.
> C>Про XRef я вроде уже сказал, что оно — рулез. И прикручивается она к > C>чему угодно, так как работает сервером. > Я про нее вспоминаю применительно к тому, что этой штуки в купе с emacs > достаточно . А для С или С с классами достаточно и cedet.
Ее достаточно для навигации, но не для поддержания проектов.
> C>Для удобного просмотра всех доступных действий. > Как я уже говорил C-h b спасет отца русской демократии.
Как-то слегка неудобно искать нужный пункт в большом плоском списке.
> C>Опять же — банальные команды редактирования через меню вызываются всего > C>несколько раз — чтобы запомнить их шорткаты. Меню нужны для сложных и > C>редких действий типа какого-нибудь "запустить в дебаггере с поддержкой > C>UML на машине в Африке через SSH поверх голубиной почты". > Допустим у нас есть некий пакет debug-via-ssh.
А может он называется ssh-debug? Или extra-ssh-debug? А может dbg-ssh? А
как насчет openssh-dbg?
Почему, например, в XEmacs есть "paren-set-mode", а не "set-paren-mode"?
И я уже на такое не раз натыкался.
> 1. Если все правильно названо, то и имеет префикс dvs
А может sshd?
> M-x dvs-<TAB>*тут мы получим список возможных комманд*
Он большой. И неструктурированый.
> Which command we will use? ssh debuguser@africa | golubinaja_pochta > decode |
А может там "pigeon_mail" или "PigeonMail" или даже "pigeon-mail"? А
может надо указывать для ssh какую-нибудь опцию типа "-" как для tar'а?
> Возражения на тему, а кто напишет чтобы все эти вопросы Where и What > задавались, > отвечу вопросом: а кто напишет и нарисует формочки и предусмотрит все > варианты > использования? Тут хоть пайпы прозрачно встраиваются.
Только ведь абослютная кастомизация всего нужна далеко не всегда — в 99%
случаев используются типовые варианты, которые вполне можно заранее
предусмотреть и автоматизировать. Ну для оставшегося 1% можно дать
доступ к командной строке.
> C>Просто так. Например, прикрутить test coverage тулзу там, или > профайлер. > C>Или в emacs'е есть уже все что нужно до конца времен? > Как показал выше все это и так легко вкручивается. Никто не говорит, что > все есть в emacs. Разговор как раз об обратном, что на все есть > сторонние тулзы > и не совсем обязательно даже встроенный дебагер. Как раз по Вашей > логике надо > чтобы и "test coverage тулзу там, или профайлер" тоже были встроены в IDE.
Да, они должны быть встроены в IDE. _НО_ не обязательно самим
производителем IDE, который должен лишь представить интерфейс для
подключения 3rd-party тулзов.
> Это я знаю... но он достаточно убогий (во всяком случае все что я видел > под VS для работы с subversion и cvs достаточно убого... особенно любов > MS на все lock ставить )
Тяжкое наследие, что поделать. Надо посмотреть на из Team Server, там
вроде все должно быть круто.
Кстати, я никогда не пользовался ни VSS, ни другими системами через SCC.
Предпочитаю командную строчку + FAR
> C>Нормальный процесс, я не говорю, что VS идеальна, но вот замены ей > C>что-то не видно. > Замены? А кто ее хочет заменить? Под вынь особенно?
Для С++ — никто. А вот для C# скоро IDEA-вцы начнут делать свою IDE.
> C>А что, все кто работает под *nix'ами обязаны любить Emacs/vim и > C>закрывать глаза на более удобные инструменты? > Ну как минимум не надо делать громких заявлений на предмет стандартов > и удобства. Везде свои законы и стандарты.
Ну и я пытаюсь выяснить, как бы их адаптировать к best practicies с
конкурирующей ОС.
> C>Да, да. И больше ничего я не умею, только еще настраиваю Mysql через > C>phpMysqlAdmin (в перерывах между *правкой ядерных модулей и > апачевских ** > C>расширений*). > Интересно в чем это делается? Особенно те 9 лет до появления интереса к > emacs/vi/...? Я догадываюсь что FAR + Ftp + ssh .
Не угадал: в FAR+smb Ну еще в MC+vim когда все падает. Просто до
недавнего времени это не было моим основным занятием.
Очень, кстати, удобно админить машины из FAR'а — расшариваю "/" через
smb для root'а и хожу себе FARом. Еще я написал себе команды в
пользовательское меню для chmod и прочей радости (работают через ssh).
eao197 wrote:
> Ну и еще такой фактор -- doxygen описания, как правило нужны для тех > фрагментов программы, которые давно разрабатывались. А в том, что я > сейчас делаю, я и так нормально ориентируюсь.
А теперь подумайте: а не лучше ли, если это все было бы доступно
непосредственно из IDE с дополнительной возможностью экспорта во внешнюю
доку?
execve wrote:
> А вообще мне эта тема напиминает то, что я слышал от одного > приятеля-дельфака примерно 8-10 лет назад. > Он тоже волей судеб был вынужден переходить на Visual Studio с Delphi, > и рассказывал, что VS — Г, а вот Delphi — действительно стандарт и > вершина мысли в области посроения UI для сред разработки.
Что самое интересное, это отчасти правда. Лет 10 назад не было
соперников для Delphi в области создания простых "формочковых"
приложений. Ну разве что VB6, но это уж слишком убогий язык.
execve wrote:
>>> Резюме одно: "со своим уставом в чужой монастырь не ходят". >>> Все твои претензии — суть "я в Windows/VisualStudio привык делать ТАК, >>> как мне сделать ТОЧНО ТАК ЖЕ в Linux/Whatever". > C>Проблема в том, что сейчас есть де-факто стандарты на IDE. > Для разработчиков под Windows.
Коих большинство. Кстати, на Mac'е тоже IDEшки весьма похожи на VS
(XCode, например).
> Остальное комментировать не буду, так как все проблемы — от этого.
А может это просто следствие проблем Юникса? Никогда такая еретическая
мысль не закрадывалась?
Quintanar wrote:
> C>Простите, эта "альтернативная" реальность занимает процентов 95% рынка, > C>так что альтернативная реальность — это emacs/vim. А причина — > C>производители IDE думают об удобстве пользователя, наравне с > C>функциональностью. > Десктопов, не забывайте добавлять.
Кроме десктопов есть еще серверы и встроеные компьютеры, непосредственно
на которых софт обычно не пишут. Есть еще суперкомпьютеры и мейнфреймы —
но это вообще отдельная параллельная вселенная.
Здравствуйте, Cyberax, Вы писали:
C>execve wrote:
>> C>Проблема в том, что сейчас есть де-факто стандарты на IDE. >> Для разработчиков под Windows. C>Коих большинство.
Какое отношение это имеет к "де-факто стандарты"?
Водителей легковушек тоже намного больше пилотов боингов.
Предлагаешь UI у боингов срочно переделать в соответствии с принципами, принятыми в обычном легковом автомобилестроении?
Чтобы случайно севшему за штурвал самолёта водителю было удобно?
C>Кстати, на Mac'е тоже IDEшки весьма похожи на VS (XCode, например).
А в Киеве дядька.
>> Остальное комментировать не буду, так как все проблемы — от этого.
C>А может это просто следствие проблем Юникса? Никогда такая еретическая C>мысль не закрадывалась?
Нет.
Мне (и не только мне) удобно с vi+CLI. И не удобно с VS.
Ещё раз: со своим уставом в чужой монастырь не ходят.
ЗЫ: А сколько тебе лет, кстати? Может мы тут зря своё время тратим?
Здравствуйте, Cyberax, Вы писали:
C>execve wrote:
>> А вообще мне эта тема напиминает то, что я слышал от одного >> приятеля-дельфака примерно 8-10 лет назад. >> Он тоже волей судеб был вынужден переходить на Visual Studio с Delphi, >> и рассказывал, что VS — Г, а вот Delphi — действительно стандарт и >> вершина мысли в области посроения UI для сред разработки.
C>Что самое интересное, это отчасти правда. Лет 10 назад не было C>соперников для Delphi в области создания простых "формочковых" C>приложений. Ну разве что VB6, но это уж слишком убогий язык.
В Visual Studio + MFC можно было делать практически всё то же самое.
Но для этого нужно было
1). Изучить (или хотя бы знать о существовании) MFC.
2). Иметь представление об Win32 API.
3). Быть готовым хоть немного поменять полученные в Delphi навыки.
Вышеописанный "программист" оказался неспособен сделать ни то, ни другое.
jazzer wrote:
> C>Про XRef я вроде уже сказал, что оно — рулез. И прикручивается она к > C>чему угодно, так как работает сервером. > Если я правильно понял, оно работает толкьо с emacs, или нет?
Оно может работать с чем угодно (в том числе и автономно). Сам xref
встает локальным сервером, работающим через сокеты. К нему коннектятся
клиенты (Emacs или jEdit). Исходники переходника к xref для Emacs и
jEdit — открыты, так что можно на их основе пришпилить xref к чему угодно.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
C>>>>В C++ в одном файле могут быть несколько классов. Как мне быстро найти, C>>>>где определен данный класс? Еще часто очень удобно посмотреть какие у C>>>>класса есть наследники и предки.
E>>>doxygen мне в этом очень помогает.
Я для той же цели использую ctags.
A ctags мы используем потому, что с ним одинаково хорошо работает и VIM, и NEdit (два главных редактора в нашем проекте).
С doxygen кто-нть интегрируется? И насколько это сложно в нем?
Раскрывает ли doxygen сишные макросы?
J>>а он отслеживает, какие файлы изменились, с тем, чтобы перепарсить только их? J>>Или он каждый раз заново парсит всю тучу файлов проекта?
E>Нет, не отслеживает.
вот и ctags не отслеживает :(
E>Но это не проблема по нескольким причинам.
E>Во-первых, doxygen работает весьма шустро.
Не знаю, насколько doxygen работает быстрее ctags. Это не наезд, я просто не знаю.
На reparse нашего огромного проекта у ctags уходит 3 минуты.
Правда, в эти 3 минуты еще входят кое-какие перловые скрипты, которые добавляют таги для всяких несишных файлов, из которых потом генерятся сишные.
В принципе, 3 минуты — это немного, и за чаем можно сходить, но часто этим не побалуешься, я просто столько не выпью :)
E>Во-вторых, в нем есть возможность создавать т.н. tag-файлы (xml-файлы с результатами предыдущего разбора) и подключать их впоследствии. Поэтому большие проекты можно разбить на несколько tag-ов и перегенерировать только то, что изменялось (правда придется делать это вручную).
NEdit позволяет подключить несколько tag-файлов.
По разным причинам проект на части разбить невозможно (dmz знает, по каким).
E>Ну и еще такой фактор -- doxygen описания, как правило нужны для тех фрагментов программы, которые давно разрабатывались. А в том, что я сейчас делаю, я и так нормально ориентируюсь.
а комментарии в коде уже не рулят?
P.S. Еще раз, я не наезжаю на doxygen, просто пытаюсь оценить его возможности с точки зрения нужд нашего проекта.
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> Ну и еще такой фактор -- doxygen описания, как правило нужны для тех >> фрагментов программы, которые давно разрабатывались. А в том, что я >> сейчас делаю, я и так нормально ориентируюсь.
C>А теперь подумайте: а не лучше ли, если это все было бы доступно C>непосредственно из IDE с дополнительной возможностью экспорта во внешнюю C>доку?
Что-то я себе это не очень представляю. Видел я в Java как это происходило с javadoc-ами: в всплывающем tooltip-е было видно совсем мало. А если класс серьезный. Что-то вроде ACE_Get_Opt? Такие вещи лично мне удобнее в соседнем браузере просматривать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
J>Раскрывает ли doxygen сишные макросы?
Вроде да. Кроме того, в нем можно в конфиге прописывать раскрытие макросов.
J>P.S. Еще раз, я не наезжаю на doxygen, просто пытаюсь оценить его возможности с точки зрения нужд нашего проекта.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Раскрывает ли doxygen сишные макросы?
E>Вроде да. Кроме того, в нем можно в конфиге прописывать раскрытие макросов.
А тяжело его настроить на работу с неизвестным ему форматом файла?
J>>P.S. Еще раз, я не наезжаю на doxygen, просто пытаюсь оценить его возможности с точки зрения нужд нашего проекта.
E>jazzer, мне кажется ты не очень представляешь себе, что такое doxygen и для чего он обычно используется. Вот, посмотри, что он строит: E>это документация по моему собственному, не маленькому проекту, E>а вот это документация по монстроидальному ACE.
Да, я уже видел сгенеренные им доки, мы используем несколько библиотек, которые как раз таким образом задокументированы.
Может быть, народ не умеет этим тулом пользоваться, потому что пока не позвонишь и не поговоришь с ними, понятно не становится.
E>Имхо, doxygen и ctags -- это разные вещи. И предназначены они для решения разных задач.
вполне может быть, просто я уцепился вот за это:
C>>В C++ в одном файле могут быть несколько классов. Как мне быстро найти,
C>>где определен данный класс? Еще часто очень удобно посмотреть какие у
C>>класса есть наследники и предки.
E>doxygen мне в этом очень помогает.
вот для быстро и удобно посмотреть (и сразу прыгнуть на объявление/определение) ctags вполне подходит.
Иными словами, я рассматриваю ctags как то, что превращает любой редактор, который умеет с ним работать (даже не с ним, а с произведенными им файлами), в мини-IDE. На сегодняшний день такими редакторами ясляются vi с производными, emacs с производными, и NEdit. Наверняка еще кто-то есть.
Ну и, соответственно, смотрю, что есть лучше и что может быть заменой ctags.
Здравствуйте, execve, Вы писали:
E>В Visual Studio + MFC можно было делать практически всё то же самое. E>Но для этого нужно было E>1). Изучить (или хотя бы знать о существовании) MFC. E>2). Иметь представление об Win32 API. E>3). Быть готовым хоть немного поменять полученные в Delphi навыки.
E>Вышеописанный "программист" оказался неспособен сделать ни то, ни другое.
Ты преувеличиваешь.
В MSVC ручной работы на порядок больше, чем в дельфях.
Здравствуйте, jazzer, Вы писали:
J>>>Раскрывает ли doxygen сишные макросы?
E>>Вроде да. Кроме того, в нем можно в конфиге прописывать раскрытие макросов.
J>А тяжело его настроить на работу с неизвестным ему форматом файла?
А что значит "неизвестный формат файла"?
J>>>P.S. Еще раз, я не наезжаю на doxygen, просто пытаюсь оценить его возможности с точки зрения нужд нашего проекта.
E>>jazzer, мне кажется ты не очень представляешь себе, что такое doxygen и для чего он обычно используется. Вот, посмотри, что он строит: E>>это документация по моему собственному, не маленькому проекту, E>>а вот это документация по монстроидальному ACE.
J>Да, я уже видел сгенеренные им доки, мы используем несколько библиотек, которые как раз таким образом задокументированы. J>Может быть, народ не умеет этим тулом пользоваться, потому что пока не позвонишь и не поговоришь с ними, понятно не становится.
Ну, doxygen способен только извлечь информацию из комментариев. А вот записать в комментарии внятную документацию он не сможет
J>
C>>>В C++ в одном файле могут быть несколько классов. Как мне быстро найти,
C>>>где определен данный класс? Еще часто очень удобно посмотреть какие у
C>>>класса есть наследники и предки.
E>>doxygen мне в этом очень помогает.
J>вот для быстро и удобно посмотреть (и сразу прыгнуть на объявление/определение) ctags вполне подходит.
Ну и для каждого класса он рисует иерархию наследования:
Вот именно об этом я и говорил.
J>Иными словами, я рассматриваю ctags как то, что превращает любой редактор, который умеет с ним работать (даже не с ним, а с произведенными им файлами), в мини-IDE. На сегодняшний день такими редакторами ясляются vi с производными, emacs с производными, и NEdit. Наверняка еще кто-то есть.
J>Ну и, соответственно, смотрю, что есть лучше и что может быть заменой ctags.
Имхо, doxygen заменой ctags не является. А вот мощным дополнением -- вполне.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
.
. А для С или С с классами достаточно и cedet.
)
.
