Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra)
@ 2006-04-04 22:08:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
По поводу предыдущего поста.
Вообще-то я не считаю большим извращением ни то, ни другое занятие (хотя Escape-Meta-Alt-Control-Shift - редактор не для слабых духом, да и С++ - тот еще язык). Но вопрос на самом деле носил сугубо прикладной характер. Мне нужны подопытные кролики.


Я со товарищи некоторое время занимаюсь софтиной, которая в идеале должна быть тулом для программирования на С++ наподобие Idea или Eclipse для Java. С одним важным отличием - оно не собирается изображать из себя IDE, а предназначено для встраивания в существующие IDE соответствующей функциональности.

В частности - для Emacs это модификация обычной С++-mode. Я вполне неплохо пользуюсь этим тулом уже несколько месяцев и в общем склонен думать, что даже в нынешнем сыром состоянии он будет полезен.

Что оно умеет - оно умеет разбирать "на лету" программы на С/С++, также на лету подсвечивать ошибки, умеет делать "умный" syntax highlighting (например функции - одним цветом, переменные - другим. енумы - третьим, типы - четвертым), умеет подсвечивать ошибки и синтаксис в макросах, умеет делать некоторые простые проверки - например - на неиспользуемые (глобально) имена, делать довольно удобную навигацию по коду (подробности ниже - это видимо главная польза), умеет делать умный name completion (в соответствии с результатами содержательного анализа кода), умеет некоторые простые рефакторинги - сейчас это rename и "превратить выражение в переменную" (introduce variable в терминах Eclipse). В принципе - рефакторинги писать просто - только это сейчас не приоритет - приоритет доведение до ума анализа С++ - сейчас есть серьезные недоделки в обработке шаблонов и еще кое в чем.

Навигация - есть функции "поиск всех использований" (в том числе - с учетом виртуальных методов и по макросам в том числе), goto def/decl, переход к наследникам/предкам класса (виртуального метода), поиск всех имен переменных/макросов/типов, начинающихся с префикса (с квалификаторами, если надо) или подходящих под образец (со *) - функция неочевидная, но на самом деле очень удобная.

Примерно так. Весьма out-of-date бумажку со скриншотами можно посмотреть здесь. Сейчас бумажка приводится в соотвествие с.

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

Замечание #2 - собака еще молодая, и там довольно много известных недоделок и просто ошибок. As is. В устранении их я заинтересован, но надо понимать, что у "Kouzdra & Co" есть определенные приоритеты. Если проблема не критическая - она вполне возможно будет отложена в долгий ящик. А возможно и нет.

Замечание #3: почему я спрашивал про С++ - по двум причинам - С++ существенно сложнее и потому является для нас приоритетом. Во-вторых - значительная часть функциональности в случае pure C существенно теряет в актуальности.

Теперь - есть естественные ограничения по ресурсам и среде - сейчас они примерно таковы - для программы на С++ объемом до 100-150 тысяч строк я ожидаю приемлемного времени отклика и потребностей по памяти (<=256 MB). Хотя при использовании очень больших (в смысле объема .h файлов) библиотек возможны проблемы. Лично у меня проект составляет около 50 тыс. строк при затратах памяти 50MB и времени реакции от 0.2-0.5" (Athlon-2500) - типичный случай до 4" (worst case)

Второе - Linux. Т.е. - под Windows оно тоже работает, но я не вполне готов сейчас бороться с артефактами Visual C++ или самой Win - если есть желающие - я могу выдать и этот вариант, но надо понимать, что вероятность геммороя существенно выше, а оперативность реакции будет ниже.

Вот. Imho тулза и сейчас полезная (невзирая на все тараканы), хотя реально она сейчас используется на 3 проектах и скорее всего на 4-ом вылезет какая-то гадость (затем нам и нужны кролики). Однако как раз гадость я постраюсь фиксить максимально оперативно.

Вот.


(Добавить комментарий)


[info]qwerty
2006-04-05 03:29 (ссылка)
Навигация - как насчет разыменования указателя на виртуальную фнукцию? :)

Народ, который пользует емакс для ЦПП, имеется в достаточном количестве. Могу призвать.

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2006-04-05 11:08 (ссылка)
Пока больших толп не надо. Реально мне для начала надо пару-тройку юзеров ( и в рамках заданных количественных ограничений) - для начального тестирования. Подождем. Я по нескольким направлениям удочки закинул - может и так наберется.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-05 21:57 (ссылка)
Ну, как хочешь. Я больших толп и не обещаю - запросто могут и не согласиться.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2006-04-05 22:21 (ссылка)
В принципе - несложно и покопаться - на уровне типов анализ полноценный. Просто не до этого сейчас. Я даже более простые вещи - вроде детектирования unused/unassigned values не делаю.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-05 22:54 (ссылка)
Ага. А на used unassigned приличный компилятор сам ругаться должен.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2006-04-06 11:02 (ссылка)
А смысл тут не в том, чтобы компилятор ругался, а в том, что такие мелочи очень удобно видеть "в реальном времени".

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-06 11:48 (ссылка)
В "реальном времени" многое удобно видеть, всего все равно сразу не написать. Компилятор запускать приходится довольно часто, и если бы он еще был бы так же быстр, как трубопаскакаль, то диагностика времени компиляции была бы почти столь же адекватна, сколь и времени редактирования. Если же компилятор не ругается (не важно, по какой причине), то все принципиально хуже.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2006-04-06 12:48 (ссылка)
Там ситуация такая - мне сейчас более чем достаточно работы по доведению до ума front-end-a, Максу хватает возни с плагином под DevStudio, то есть - анализы писать несложно, но несколько преждевремено.

К тому же - это все таки редактор - то есть первые на очереди - простые рефакторинги, кое-какие inspections - например насчет нужных/ненужных includes, и т.п. Сложные анализы как раз на заднем фоне.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-06 22:15 (ссылка)
С ненужными инклудами, кстати, не очень просто.

(Ответить) (Уровень выше)


[info]lolepezy
2006-04-05 09:16 (ссылка)
Красивенькая. Весьма интересно.

А что вообще предполагется для темплейтов ?
Все IDE, которыми я пользовался, сдуваются (вполне логично, конечно) на шаблонах.
Ну, скажем, name-completion для typename Type::начало не в состоянии
сделать ни одна (понятно, что теоретически это вообще невозможно, но на практике
полной индексацией всех исходников - можно).

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2006-04-05 11:12 (ссылка)
В макросах (которые близки к шаблонам) аналогичная функциональность работает (по фактическим вызовам).
С шаблонами - как раз в этом и состоит основаная недоделка (ну есть еще мелочи, вроде не вполне корректной обработки числовых константных параметров и шаблонов-параметров). Планируется так: анализ по всем инстанциированиям шаблонов и подсветка ошибок + функциональность вроде completion и (что более нетривиальная вещь) - учет в rename и т.п. - если есть два класса с полем x, которое используется в одном и том же шаблоне - это x на самом в смысле переименования (а может и поиска - тут надо думать, как удобнее) одно и то же - примерно как виртуальные методы.

В принципе - там на неделю примерно работы.

(Ответить) (Уровень выше)


[info]potan
2006-04-05 13:02 (ссылка)
У меня это будет шестая попытка перейти на Emacs...
А давно FAR и VC давно под Linux портировали? :-)

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2006-04-05 20:42 (ссылка)
"под Windows оно тоже работает" (с) Я :)

(Ответить) (Уровень выше)


[info]ifp5
2006-04-05 14:19 (ссылка)
Тулза интересная. А можно FreeBSD'шную версию?

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2006-04-05 20:44 (ссылка)
Проблема в основном в том, чтобы собрать - то есть оно не проблема даже, но требует определенных усилий. Но вроде под FreeBSD линуксовые исполняемые модули запускаются? Там схема такая - исполняемый модуль, которому на вход кладутся команды, а на выходе получаются ответы + пачка скриптов для emacs, которые организуют интерфейс.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ifp5
2006-04-06 10:37 (ссылка)
А. Не думал что это проблема. Бинарники, по крайней мере ELF, запускаются, но иногда заколебешься подбирать библиотеки и пр. окружение, если нет соотв. дистрибутива. У меня по трудозатратам получалось поболее чем сборка gcc cross toolchain'а (за обилие дистрибутивов и комбинаций софта в них сильно не люблю линух).

Желательно собрать тогда под что-нибудь совместимое из:
- Debian 3
- FC 3
- Redhat 7.3, 8, 9
- Suse 9.1,9.2,9.3
Или статикой. :)

Если это проблематично, могу собрать gcc cross toolchain или дать шелл на FreeBSD.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Поставил тут xemacs
[info]ifp5
2006-04-06 12:06 (ссылка)
Как же он тормозззззииииииииттттттт. :) Последний раз пробовал его в 1997 году на K6-200/64Mb. Сейчас на тестовом Dual Xeon 2.4Gz/2Gb ощущения примерно такие же.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Поставил тут xemacs
[info]kouzdra
2006-04-06 12:33 (ссылка)
А зачем XEmacs? Обычный работает быстро. Я, кстати, не поручусь за то, что под XEmacs скрипты будут работать - не проверял.

(Ответить) (Уровень выше)


[info]kouzdra
2006-04-06 12:45 (ссылка)
Это не то, чтобы проблема, но сейчас оно не в том состоянии, чтобы хотелось расползаться по поддержке кучи платформ. Я просто знаю по опыту, что это сильно увеличивает нагрузку по поддержке.

(Ответить) (Уровень выше)


[info]qwerty
2006-04-05 23:45 (ссылка)
А вот, кстати, что ты делаешь с условной компиляцией? Типа, мэйкфайл в зависимости от разных условий задает пачку внешних дефайнов для компиляции. От этих дефайнов могут зависить макроопределения в исходниках и проч. Не завелось ли у тебя мультивариантности анализа?

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2006-04-06 11:01 (ссылка)
Не делаю - обдумаывалось, и в общем даже понятно, как делать, но тоже не на первом месте.

(Ответить) (Уровень выше)


[info]awson.livejournal.com
2006-04-06 04:00 (ссылка)
Я emacs ПОКА не пользуюсь, но буквально щас собрался.

У меня ситуация причудливая. С одной стороны - много лет под маздаем, с другой стороны - сейчас основной инструмент - GHC (Glasgow Haskell Compiler), а следовательно для всего С/С++ stuff'a - gcc (mingw).

Реально работаю .. да-да - в том самом FAR'e.

Для большого рефакторинга (а я делаю его ЧАСТО) хочется IDE.

Для g++ даже под маздаем IDE - не проблема, codeblocks, например. Но хотелось, чтобы было все вместе. Visual Haskell не канает, поскольку используемый там 6.5 snapshot уже совсем древний, а собрать самому на базе свежего невозможно - нужен доступ к VSIP программе. Eclipse в части C++ меня, в принципе, устраивает, но ecslipsefp для Haskell'а пока не вполне работоспособен - падает на моем Template Haskell коде.

В общем - я окончательно решился-таки попробовать (X)Emacs. Поэтому, если что есть для C++ - все хорошо. У меня, правда, фундаментальный вопрос - откуда С++ - frontend - самодельный, от gcc или чего-то еще?

(Ответить) (Ветвь дискуссии)


[info]qwerty
2006-04-06 04:38 (ссылка)
Думаю, что самодельный. Просто из g++ утянуть фронтенд не получится - ПЯ низкоурвоневый, а в .tu недопереваренная херь с неточной привязкой к сырцам, причем меняющаяся как попало от версии к версии.

EDG хороший, но давно уж стал сильно коммерческим.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]awson.livejournal.com
2006-04-06 04:53 (ссылка)
Разговоры про .tu я помню. G. Dos Reis обещал это дело не только поддерживать, но и чуть-ли не довести до юзабельного вида. Я за этим делом не следил, но надежду, что в 4.1 оно сильно улучшилось, питал.

Питал я ее, конечно, вполне теоретически, но чувствовал бы себя намного комфортнее, если б оно было.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-06 05:40 (ссылка)
Я .tu давно пользуюсь для глубокого статического анализа. Очень специального, впрочем. Ничего особенно хорошего про него сказать не могу. Файлы дюже огромные, строчные литералы в файлах не приведены к внешнему виду (не закавычены, без ескайп-последовательностей перед непечатными литерами, и оттого в общем случае файл корректно попарсить невозможно), бывают висячие ссылки на несуществующие узелки, бывают недогенеренные до конца поддеревца, типовой анализ до конца не произведен, вызовы деструкторов не сгенерированы, break, continue и case к соответствующим циклам и переключателям не привязаны, вложенность областей действия явно не указана, искусственно созданные для технических целей области действия от настоящих никак не отличаются. С шаблонами жопа. Структура узелков сильно меняется от версии к версии, а сами деревяхи меняются даже в пределах одной и той же версии для разных целевых платформ. Т.е. лучше, чем ничего, но парсер .tu файлов приходится менять непрерывно, подстраиваясь под особенности, и никакой неподвижной точки лично мне пока не видать.

Был бы EDG не сильно коммерческим, с удовольстивем бы на него перелез.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2006-04-06 12:44 (ссылка)
Я когда-то давно пробовал выдирать - то еще удовольствие.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-06 22:12 (ссылка)
Я тоже пробовал - поэтому там "но ..." и написано.

Безотносительно к данному конкретному мероприятию - а ведь забавно было бы сделать инкрементный редактор/компилятор к плюсизму с типичным временем реакции порядка паскалевского. Памятей уже есть дофига, вычислительной мощности - тоже, осталось все, что можно, в инкрементную форму перевести. Синт. разбор и большинство оптимизаций точно можно.

(Ответить) (Уровень выше)


[info]potan
2006-04-07 19:47 (ссылка)
А CKit или cTool не подходят?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2006-04-07 22:00 (ссылка)
Мне нужно разбирать ЦПП, а не Ц, и не просто синтаксически, а построить полноценное представление в высокоуровневом ПЯ с правильно привязанными идентификаторами, типовым анализом, разрешенными структурными переходами, сгенеренными вызовами конструкторов и деструкторов. Семантики в ЦПП сложные, писать их руками с нуля не хочется.

(Ответить) (Уровень выше)


[info]kouzdra
2006-04-06 12:40 (ссылка)
Фронтенд - самодельный, иначе приличного времени реакции не обеспечить (не говоря уж о том, что из GCC-шного задерешься вытаскивать инфу). Работает более или менее прилично (хотя есть довольно много и недоделок и багов) - но для этой функциональности на самом деле допустима куда меньшая точность, чем для компилятора.

Вообще - приличных IDE для С++ мне не встречалось. Собственно - потому и занялся. Как ни странно, но Emacs меня даже "в чистом виде" устраивает больше, чем Eclipse CDT (он глючит и тормозит совсем дико) или DevStudio.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kouzdra
2006-04-06 12:41 (ссылка)
Только существенное "но" - под вин Emacs должен быть не из Cygwin-овского пакета.

(Ответить) (Уровень выше)