Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
В таком контексте использую Emacs, на Windows в том числе.
В него интегрируется простая навигация по символам на базе GNU Global — она не требует модели проекта, быстро индексирует, но как следствие не точна, тем не менее для быстрой навигации по случайному проекту вполне годится (для точной есть Rtags на базе Clang).
Также есть встроенный интерактивный grep.
В нём же навигация по файлам на базе Projectile + Helm — вводишь кусочки пути к файлу, и в ответ получаешь список на выбор, отфильтрованный fuzzy search.
В нём же есть интеграция с VCS, например Magit для Git.
Помимо этого разнообразные закладки, разбиение фрейма на окна, множественные фреймы и т.д. и т.п.
Здравствуйте, tehKosh, Вы писали:
EP>>В таком контексте использую Emacs, на Windows в том числе K>Там внутри будут различные на выбор фронэнды к семейству ctags, но как они справляются с кодом имеющим windows-специфику?
Я под Windows использую GNU Global, это gtags. Windows-специфики в моих проектах либо нет, либо очень немного, но не думаю что с ней будут какие-то особенные проблемы — будет точно такая же низкая точность gtags как и для остального C++ кода.
Для точного разбора нужны define'ы, include dir's и т.п., то есть модель проекта, и понимание языка — такие утилиты сейчас в основном на базе Clang.
K>Второе — нужно пользовать в связке с cygwin?
Нет, есть готовая версия собранная через MinGW — выглядит вполне native'но, понимает пути и т.п. Никаких дополнительных оболочек типа MSYS ставить не нужно.
GNU Global брал вот отсюда.
Есть конечно версия Emacs и для Cygwin, но я её даже не пробовал, предполагаю что у неё будет множество проблем с интеграцией с остальными Windows приложениями, как впрочем и у других Cygwin программ.
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Если исходники знакомы (предыдущии версии проекта, BOOST/STL или что-то подобное), то Vim + ag и иногда CTags.
Если исходники не знакомые, то ничего удобнее и проще чем связка Doxygen + GraphViz нет и быть не может.
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
QT Creator, импортируешь исходники из директории, а он в этих исходниках дает переход к месту определения символа, места использования символа и тому подобные возможности IDE, полноценную навигацию по символам. Иногда, правда, бывает необходимость подправить импортированный проект, указать, например. где boost лежит, иначе не получается нормально работать с символами внутри BOOST_FOREACH, например.
Здравствуйте, tehKosh, Вы писали:
K>я тоже пользовался им, складывается впечатление что под виндовс вообще нет подобного ему средства — чтобы прямо из коробки, ничего не допиливая, просто указал папку и работает
Ну, вообще QT Creator примерно так и делает, открываешь папку с любым проектом на плюсах, и он дает там все, что нужно для чтения исходников с пониманием всяких инклудов и дефайнов.
иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода
те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы
какими средствами пользуетесь?
F>SourceInsight
я тоже пользовался им, складывается впечатление что под виндовс вообще нет подобного ему средства — чтобы прямо из коробки, ничего не допиливая, просто указал папку и работает
но пользовался ворованной копией
EP>В таком контексте использую Emacs, на Windows в том числе
Там внутри будут различные на выбор фронэнды к семейству ctags, но как они справляются с кодом имеющим windows-специфику?
Второе — нужно пользовать в связке с cygwin?
VTT>Студия.
Но зачем тянуть целую студию, когда требуется, по сути, простой текстовый редактор с подсветкой синтаксиса и (опционально) джампами к определениям символов?
Здравствуйте, jahr, Вы писали:
J>Ну, вообще QT Creator примерно так и делает, открываешь папку с любым проектом на плюсах, и он дает там все, что нужно для чтения исходников с пониманием всяких инклудов и дефайнов.
Я был бы только рад этому.
Для разработки от "текстового редактора" хочется синтаксиса, автодополнения, поддержки проектов и отладчика — с этим многие справляются.
А вот для изучения исходников нужно чуть другое: помимо простого "Goto declaration/definition" хочется удобной навигации по типам/функциям/переменным с поддержкой истории переходов (как в браузере вперёд/назад), хочется поиска по имени файла, поиска символа в файле/проекте, поиска ссылок на символ (простой поиск текста здесь идёт лесом). Так тут даже VS+VAX не так удобны.
VTT>вы уж определитесь, "простой" или "с преферансом и куртизанками"
А что, редактор с подсветкой синтаксиса и прыжками по тегам не может быть простым? Посмотрите на тот же Vim -- легковесный и малотребовательный к памяти, в отличие от долго загружающейся и отжирающей память студии.
Здравствуйте, b0r3d0m, Вы писали:
VTT>>вы уж определитесь, "простой" или "с преферансом и куртизанками" B>А что, редактор с подсветкой синтаксиса и прыжками по тегам не может быть простым? Посмотрите на тот же Vim -- легковесный и малотребовательный к памяти
Да, редактор с подсветкой синтаксиса и прыжками по тегам не может быть простым.
В простых редакторах максимум может быть подсветка по ключевым словам при помощи простого парсера и/или регулярок.
А чтобы получить хоть какую-то семантическую подсветку, прыжки и т.п. очумелые ручки начинают прикручивать к вимам/емаксам пачки плагинов разной степени тяжести и кривизны.
К таким франкенштейнам эпитеты "простой", "легковесный", "малотребовательный к памяти" вряд ли применимы.
B>в отличие от долго загружающейся и отжирающей память студии
Ну вот не надо... Грузится шустро, памяти ест меньше, чем браузер.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, b0r3d0m, Вы писали:
VTT>>вы уж определитесь, "простой" или "с преферансом и куртизанками" B>А что, редактор с подсветкой синтаксиса и прыжками по тегам не может быть простым? Посмотрите на тот же Vim -- легковесный и малотребовательный к памяти, в отличие от долго загружающейся и отжирающей память студии.
Vim легковесный, но не простой, с его-то кривой обучения. Простой это например про Notepad++, к нему вроде тэги тоже прикручиваются.
VTT>>Студия. B>Но зачем тянуть целую студию, когда требуется, по сути, простой текстовый редактор с подсветкой синтаксиса и (опционально) джампами к определениям символов?
Потому, что студия уже стоит?
Если не стоит — стоит Eclipse/CLion/QTCreator/...
Или вы и код в Виме пишете?
Здравствуйте, 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 сорцами", кроме совсем тривиальных случаев, у тебя уйдёт несколько часов минимум. Если же не делать проект, то над задачей можно начинать работать сразу же, а то и вовсе решить её за десятки минут.
Здравствуйте, flаt, Вы писали:
F>Может. Но да, на безрыбье и Doxygen спасал. А ещё была такая штука как Understand C++, но она умирала на больших сорцах типа WinNT.
Doxygen вообще ни на чем не умирает, а такие классные схемки (наследования, графы вызовов, зависимости между файлами/директориями) как GraphViz вообще на моей памяти ни один инструмент по произвольной папке с исходниками не строит
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Если по быстрому что-то глянуть, то голый vim + grep поиском по файлам, даже ctags не заморачиваюсь.
Если сложное/долгое, то VS+VA. Некоторые линуксовые сорцы через define-ы иногда на удивление просто и собираться заставить.
SourceInsight упомянутый выше когда-то смотрел, но мне не пошел.
Здравствуйте, tehKosh, Вы писали:
K>иногда нужно "пропахать" исходники какой-нибудь сторонней программы/библиотеки либо частей, те не пытаться откомпилировать/собрать, а только чтение кода K>те сидишь на windows, а надо смотреть надо те сорцы, которые компилятся в старых версиях vs, в билдере, линуксовые сорцы K>какими средствами пользуетесь?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Потому что может не быть всех необходимых зависимостей, может не быть всех необходимых утилит для этапа конфигурации и т.п. EP>Потому что на это может уйти несколько часов, или даже дней, в зависимости от особенностей проекта. При том что исходная задача что-то быстро посмотреть в стороннем проекте может быть решена за 5 минут.
Быстро посмотреть обычно можно и в браузере. А если разбираться по-нормальному, то можно и некоторое время уделить и поиску зависимостей и настройке.
EP>Это и не нужно. У него же будет название? А уж из названия будет понятно что происходит (причём особо неважно что перед нами — макрос или функция).
угу, или тип, или переменная, или кусок данных...
Учитывая крайнее скупердяйство многих разработчиков на буквы, понять, что это вообще такое, с ходу можно далеко не всегда.
EP>На "сделать студийный проектик, подтянуть зависимости, поработать с linux сорцами", кроме совсем тривиальных случаев, у тебя уйдёт несколько часов минимум. Если же не делать проект, то над задачей можно начинать работать сразу же, а то и вовсе решить её за десятки минут.
Ну вот не надо додумывать про "несколько часов минимум". Обычно минут 5 — 15.
Покопаться иногда приходится, конечно, но это особые случаи, например древние исходники под DOS или частично утерянные.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EP>>Потому что может не быть всех необходимых зависимостей, может не быть всех необходимых утилит для этапа конфигурации и т.п. EP>>Потому что на это может уйти несколько часов, или даже дней, в зависимости от особенностей проекта. При том что исходная задача что-то быстро посмотреть в стороннем проекте может быть решена за 5 минут. VTT>Быстро посмотреть обычно можно и в браузере.
Во-первых для браузера не всегда есть готовое, а редактор типа Emacs/Vim/Sublime/Notepad++ — всегда под рукой. И непонятно чем браузер удобней редактора.
Во-вторых даже если и есть, то часто без кликабельных тэгов — просто repo viewer.
В-третьих нет полноценного поиска а-ля grep/ack/ag.
VTT>А если разбираться по-нормальному, то можно и некоторое время уделить и поиску зависимостей и настройке.
Это всегда можно успеть.
EP>>Это и не нужно. У него же будет название? А уж из названия будет понятно что происходит (причём особо неважно что перед нами — макрос или функция). VTT>угу, или тип, или переменная, или кусок данных...
Для беглого просмотра не обязательно в голове выводить типы всех выражений и т.п. Например для понимания особо без разницы for_each_something это шаблон функции, или автор по какой-то причине решил использовать макрос да ещё и lowercase.
VTT>Учитывая крайнее скупердяйство многих разработчиков на буквы, понять, что это вообще такое, с ходу можно далеко не всегда.
Скупердяйство обычно происходит внутри тел функций, для локальных имен.
EP>>На "сделать студийный проектик, подтянуть зависимости, поработать с linux сорцами", кроме совсем тривиальных случаев, у тебя уйдёт несколько часов минимум. Если же не делать проект, то над задачей можно начинать работать сразу же, а то и вовсе решить её за десятки минут. VTT>Ну вот не надо додумывать про "несколько часов минимум". Обычно минут 5 — 15.
5-15 минут это только если проект изначально рассчитан в том числе на Windows (например CMake), и имеет минимум зависимостей.
