Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Если разово, то Notepad++ или какой-нибудь Eclipse|CodeBlocks.
Если постоянно и долго, то могу и соответствующую софтину поставить.
Здравствуйте, flаt, Вы писали:
F>А вот для изучения исходников нужно чуть другое: помимо простого "Goto declaration/definition" хочется удобной навигации по типам/функциям/переменным с поддержкой истории переходов (как в браузере вперёд/назад), хочется поиска по имени файла, поиска символа в файле/проекте, поиска ссылок на символ (простой поиск текста здесь идёт лесом). Так тут даже VS+VAX не так удобны.
Все это есть в креаторе.
VTT>А чтобы получить хоть какую-то семантическую подсветку, прыжки и т.п. очумелые ручки начинают прикручивать к вимам/емаксам пачки плагинов разной степени тяжести и кривизны.
Подсветка синтаксиса у Vim из коробки, включается командой :syntax on.
Прыжки? Фиг знает, я и без них живу, никаких ctags и прочего не настраивал. Пользуюсь поиском по названию (выделяешь слово, нажимаешь * и прыгаешь на места, где оно встречается).
VTT>Ну вот не надо... Грузится шустро, памяти ест меньше, чем браузер.
Давайте хвалить студию за то, что она ест памяти меньше, чем браузер, который, блин, съедает аж больше гига при старте!
У меня студия ест ~250Mb на небольшом проекте, Vim на таком же кол-ве файлов ~10Mb. И работает гораздо шустрее.
EP>Vim легковесный, но не простой, с его-то кривой обучения
Да там команд-то, если исключительно для чтения исходников... Vimtutor'а хватит точно. Но Notepad++, конечно, быстрее освоить, это да.
Здравствуйте, flаt, Вы писали:
B>> Но Notepad++, конечно, быстрее освоить, это да. F>Вот только в изучении он ничем не поможет — ведь там только подсветка синтаксиса.
Google говорит что к нему прикручиваются например тэги.
То, что имеется в виме (и других текстовых редакторах) до полноценной подсветки синтаксиса не дотягивает.
Иначе никто бы не стал заморачиваться с хитрыми дополнительными плагинами на ctags или clang.
Чтобы полноценно работать с большой кодовой базой простой подсветки скобочек и ключевых слов явно не достаточно.
Требуется, чтобы редактор разбирался с семантикой в коде и с взаимосвязью файлов внутри проекта и снаружи.
С учетом сложности разбора с++ и полнейшего плюрализма среди разработчиков научить редактор этому крайне нетривиальная задача.
Даже несмотря на появление в последнее время перспективных инструментов (на основе того же clang / llvm) какого-то значительного прогресса я не наблюдаю.
Ну и говорить о простоте и легковесности при их использовании было бы странно.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>То, что имеется в виме (и других текстовых редакторах) до полноценной подсветки синтаксиса не дотягивает.
Супер семантическая подсветка синтаксиса для быстрого просмотра стороннего проекта не нужна.
Да и невозможна для C++ без модели проекта, как минимум из-за препроцессора.
VTT>Иначе никто бы не стал заморачиваться с хитрыми дополнительными плагинами на ctags или clang.
Заморачиваются не из-за подсветки, а из-за перехода по символам.
Если же брать редактирование проекта (а не просмотр как у ТС), то помимо символов ещё нужно автодополнение и фоновая компиляция с подсветкой ошибок.
VTT>Чтобы полноценно работать с большой кодовой базой простой подсветки скобочек и ключевых слов явно не достаточно.
С чего ты взял что нужна какая-то мощная "подсветка"?
VTT>Требуется, чтобы редактор разбирался с семантикой в коде и с взаимосвязью файлов внутри проекта и снаружи.
Для быстрой навигации по стороннему проекту вообще достаточно grep, тэги тут приятное дополнение.
А для "взаимосвязи файлов внутри проекта" нужно иметь модель проекта, которой нет по условиям задачи — где ты её брать собрался?
VTT>Даже несмотря на появление в последнее время перспективных инструментов (на основе того же clang / llvm) какого-то значительного прогресса я не наблюдаю.
Утилиты на базе Clang требуют модель проекта. Обычно достаточно того json что выдаёт CMake.
VTT>Ну и говорить о простоте и легковесности при их использовании было бы странно.
Если брать условия задачи ТС (без модели проекта) — то там будет что-то типа GTags/CTags — и это действительно легковесно. Запустил в папке с проектом простую команду, и редактор автоматом подцепляется к тэгам. Вполне легковесно и просто
Ну знаете, если вам надо просто текст почитать, так это часто можно сделать прямо в браузере, открыл где-нить на гитхабе или в редмайне файлик и готово.
А чтоб хоть немного разобраться, как оно работает, то без толковой подсветки не обойтись.
Без учета препроцессора многое читать же вообще невозможно.
И как раз "модель проекта" — это то, с чего стоит начинать знакомство.
Во всяком случае я так обычно и делаю, благо какой-нибудь проектный файл обычно имеется, хотя бы даже make / cmake.
И да, обычно я делаю из этого проект под мою IDE и уже в ней начинаю глубже разбираться.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Ну знаете, если вам надо просто текст почитать, так это часто можно сделать прямо в браузере, открыл где-нить на гитхабе или в редмайне файлик и готово.
Не просто читать, а например ещё и перескакивать между файлами, ставить закладки, открывать несколько окон side-by-side, и т.д. и т.п.
VTT>А чтоб хоть немного разобраться, как оно работает, то без толковой подсветки не обойтись.
Для меня семантическая подсветка стоит где-то на последнем месте по приоритету. Некоторые даже вообще смотрят код без всякой подсветки.
Непониманию почему ты так акцентируешь внимание именно на семантической подсветке. Может ты имеешь в виду ещё что-то помимо подсветки?
VTT>Без учета препроцессора многое читать же вообще невозможно. VTT>И как раз "модель проекта" — это то, с чего стоит начинать знакомство.
Я про ту модель, которая описывает флаги компиляции, include dirs и прочее. Обычно для понимания кода это вообще не нужно, а вот для точных утилит — да, обязательно.
VTT>Во всяком случае я так обычно и делаю, благо какой-нибудь проектный файл обычно имеется, хотя бы даже make / cmake. VTT>И да, обычно я делаю из этого проект под мою IDE и уже в ней начинаю глубже разбираться.
Только это всё не соответствует условию задачи ТС.
те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы
Здравствуйте, Evgeny.Panasyuk, Вы писали:
VTT>>А чтоб хоть немного разобраться, как оно работает, то без толковой подсветки не обойтись.
EP>Для меня семантическая подсветка стоит где-то на последнем месте по приоритету. Некоторые даже вообще смотрят код без всякой подсветки. EP>Непониманию почему ты так акцентируешь внимание именно на семантической подсветке. Может ты имеешь в виду ещё что-то помимо подсветки?
VTT>>Без учета препроцессора многое читать же вообще невозможно. VTT>>И как раз "модель проекта" — это то, с чего стоит начинать знакомство.
EP>Я про ту модель, которая описывает флаги компиляции, include dirs и прочее. Обычно для понимания кода это вообще не нужно, а вот для точных утилит — да, обязательно.
Как это не нужно? Без инклюдов и понимания зависимостей далеко не уехать.
И без работающего препроцессора тоже не обойтись.
Причем не только для подсветки макросов или затенения неактивных блоков conditional compilation, но и для разворачивания макросов.
Кроме того, я постоянно использую подсказки с выведенным типом, цепочки вызовов, навигацию по дереву типов и т.п.
Да, это совсем не так хардкорно, как чтение в окошке терминала, и навыки нахождения ошибок в программах на листочках у меня не развиты.
Но если есть возможность использовать сomputer-aid, то отчего ей не воспользоваться?
VTT>>Во всяком случае я так обычно и делаю, благо какой-нибудь проектный файл обычно имеется, хотя бы даже make / cmake. VTT>>И да, обычно я делаю из этого проект под мою IDE и уже в ней начинаю глубже разбираться.
EP>Только это всё не соответствует условию задачи ТС. EP>
EP>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы
Почему же не соответствует?
С сорцами из старых студий проблем меньше всего.
С линуксовыми практически всегда есть заморочки, но тоже обычно не проблема.
Вообще в студии скоро обещают полноценную разработку под линуксы из коробки, ну а пока есть VisualGdb. Или eclipse.
Но даже без всего этого вполне можно работать.
Из билдера исходники мне только пару раз попадались, но и то без VLC.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EP>>Я про ту модель, которая описывает флаги компиляции, include dirs и прочее. Обычно для понимания кода это вообще не нужно, а вот для точных утилит — да, обязательно. VTT>Как это не нужно? Без инклюдов и понимания зависимостей далеко не уехать. VTT>И без работающего препроцессора тоже не обойтись.
Вполне можно обойтись и без того и без другого.
VTT>Причем не только для подсветки макросов или затенения неактивных блоков conditional compilation, но и для разворачивания макросов.
Разворачивать макрос для понимания не нужно. Обычно достаточно названия. Если нет — то одним хоткеем переходим к его определению.
Разворачивание нужно например при отладке, о которой речи не идёт. Да и опять таки — для правильного разворачивания нужна модель проекта.
VTT>Кроме того, я постоянно использую подсказки с выведенным типом, цепочки вызовов, навигацию по дереву типов и т.п.
Это всё здорово когда есть модель проекта. В нашем случае её нет.
VTT>Да, это совсем не так хардкорно, как чтение в окошке терминала,
Если "окошко терминала" это кивок в сторону Emacs — то зря, у него есть полноценная GUI оболочка (которую я постоянно использую), с поддержкой разноразмерного шрифта в рамках одного "вида", и даже картинок. "Окошко терминала" это лишь приятный бонус.
VTT>и навыки нахождения ошибок в программах на листочках у меня не развиты.
Так этого и нет в требованиях ТС.
VTT>Но если есть возможность использовать сomputer-aid, то отчего ей не воспользоваться?
От того что нет этой возможности в заданных условиях
EP>>Только это всё не соответствует условию задачи ТС. EP>>
EP>>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы
VTT>Почему же не соответствует? VTT>... VTT>С линуксовыми практически всегда есть заморочки, но тоже обычно не проблема.
Да например банально нет зависимости с её заголовками — она в общем-то для изучения проекта не особо и нужна, но без неё точного разбора не будет
BE>Если постоянно и долго, то могу и соответствующую софтину поставить.
Ну да, я тоже так делаю, только ставлю не на живую машину, а на соответствующую виртуалку + активно использую снапшоты образов. Это для тех сорцов, к которым часто обращаюсь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вполне можно обойтись и без того и без другого.
А вот мне трудно без них обойтись.
EP>Это всё здорово когда есть модель проекта. В нашем случае её нет.
С чего вы взяли, что ее нет? И даже если ее нет, то почему бы ее не сделать?
EP>Разворачивать макрос для понимания не нужно. Обычно достаточно названия. Если нет — то одним хоткеем переходим к его определению.
Что-то вы уже сами себе противоречите.
Без надлежащей модели проекта и работающего препроцессора вообще невозможно определить (в общем случае), что является макросом, а что нет.
И тем более не получится прыгать к определениям, да и найти эти определения и объявления будет крайне проблематично (при чем это не только к макросам относится).
EP>Так этого и нет в требованиях ТС.
EP>От того что нет этой возможности в заданных условиях
EP>>>Только это всё не соответствует условию задачи ТС. EP>>>
EP>>>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы
VTT>>Почему же не соответствует? VTT>>... VTT>>С линуксовыми практически всегда есть заморочки, но тоже обычно не проблема.
EP>Да например банально нет зависимости с её заголовками — она в общем-то для изучения проекта не особо и нужна, но без неё точного разбора не будет
"требования" ТС сводятся просто к тому, что он сидит на windows
Что помешает ему сделать студийный проектик, подтянуть зависимости, поработать с linux сорцами?
Мне вот ничего не мешает.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Никак не читаю, что я в них не видел, к тому же это вредно для глаз. Достаточно посмотреть на работу программы и с ней всё ясно.
Здравствуйте, VTT, Вы писали:
EP>>Это всё здорово когда есть модель проекта. В нашем случае её нет. VTT>С чего вы взяли, что ее нет?
Потому что может не быть всех необходимых зависимостей, может не быть всех необходимых утилит для этапа конфигурации и т.п.
VTT>И даже если ее нет, то почему бы ее не сделать?
Потому что на это может уйти несколько часов, или даже дней, в зависимости от особенностей проекта. При том что исходная задача что-то быстро посмотреть в стороннем проекте может быть решена за 5 минут.
EP>>Разворачивать макрос для понимания не нужно. Обычно достаточно названия. Если нет — то одним хоткеем переходим к его определению. VTT>Что-то вы уже сами себе противоречите. VTT>Без надлежащей модели проекта и работающего препроцессора вообще невозможно определить (в общем случае), что является макросом, а что нет.
Это и не нужно. У него же будет название? А уж из названия будет понятно что происходит (причём особо неважно что перед нами — макрос или функция).
VTT>И тем более не получится прыгать к определениям, да и найти эти определения и объявления будет крайне проблематично (при чем это не только к макросам относится).
Это если делать точный поиск. В Gtags не точный, например есть false-positives, и это вполне приемлемо, главное не забывать про эту особенность. В крайнем случае есть grep и прочие ag/ack.
EP>>Да например банально нет зависимости с её заголовками — она в общем-то для изучения проекта не особо и нужна, но без неё точного разбора не будет VTT>"требования" ТС сводятся просто к тому, что он сидит на windows VTT>Что помешает ему сделать студийный проектик, подтянуть зависимости, поработать с linux сорцами? VTT>Мне вот ничего не мешает.
На "сделать студийный проектик, подтянуть зависимости, поработать с linux сорцами", кроме совсем тривиальных случаев, у тебя уйдёт несколько часов минимум. Если же не делать проект, то над задачей можно начинать работать сразу же, а то и вовсе решить её за десятки минут.
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Если исходники знакомы (предыдущии версии проекта, BOOST/STL или что-то подобное), то Vim + ag и иногда CTags.
Если исходники не знакомые, то ничего удобнее и проще чем связка Doxygen + GraphViz нет и быть не может.
Здравствуйте, flаt, Вы писали:
F>Может. Но да, на безрыбье и Doxygen спасал. А ещё была такая штука как Understand C++, но она умирала на больших сорцах типа WinNT.
Doxygen вообще ни на чем не умирает, а такие классные схемки (наследования, графы вызовов, зависимости между файлами/директориями) как GraphViz вообще на моей памяти ни один инструмент по произвольной папке с исходниками не строит
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Если по быстрому что-то глянуть, то голый vim + grep поиском по файлам, даже ctags не заморачиваюсь.
Если сложное/долгое, то VS+VA. Некоторые линуксовые сорцы через define-ы иногда на удивление просто и собираться заставить.
SourceInsight упомянутый выше когда-то смотрел, но мне не пошел.
