мне надо мигрировать приложение с win на linux
примерно несколько сот тыс строк
состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
уже понятно что часть кода реально не используеться
есть ли какая либо возможность определить какой код реально используеться в приложении
Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
1. Собираете всё в статические либы.
2. Потом компилируете целевые исполняемые файлы, генерируя при этом map файл
3. Затем парсите его и выделеяте то что используются
4. ...
5. PROFIT
Здравствуйте, flаt, Вы писали:
F>Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
а можно название 1-2 таких утилит для примера
я сейчас анализирую но кода овер дофига (хотя некоторые стратегии я придумал)
линкер не вариант тк конечная цель сэкономить время на переноси исходного кода
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
clion вроде умеет, но я давно его не использовал
поэтому "вроде".
Здравствуйте, sergey2b, Вы писали:
S>линкер не вариант тк конечная цель сэкономить время на переноси исходного кода
Почему не вариант?
Ты просто решил, что надо на целевом линуксе смотреть, что выкинулось, а что нет. А надо смотреть виндовый вариант, что в нем используется, и от этого плясать.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, flаt, Вы писали:
F>>Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
S>а можно название 1-2 таких утилит для примера
Линкер — норм. Если он выкинул что-то, то это явно не нужно.
Другое дело, что линкер и прочие map-файлы не смогут обнаружить, например, что реально функция fn в таком фрагменте не вызывается: if (sinf(x) > 2.0f) { fn(); }
А source based code coverage как раз разметит, что при использовании программы условие в этой строке не становилось истинным никогда, и соответственно функция fn не нужна (если она больше нигде не вызывается).
W>Другое дело, что линкер и прочие map-файлы не смогут обнаружить, например, что реально функция fn в таком фрагменте не вызывается: if (sinf(x) > 2.0f) { fn(); }
W>А source based code coverage как раз разметит, что при использовании программы условие в этой строке не становилось истинным никогда, и соответственно функция fn не нужна (если она больше нигде не вызывается).
"В военное время значение синуса может достигать и четырех!"
А вообще -- есть риск "не поймать" обработчики исключительных ситуаций, например таймаут при запросе в БД, исчерпание места на диске и т.п.
Линкер в этом отношении надежнее: то что он не взял -- портировать не нужно.
Здравствуйте, K13, Вы писали:
K13>А вообще -- есть риск "не поймать" обработчики исключительных ситуаций, например таймаут при запросе в БД, исчерпание места на диске и т.п.
Конечно. Именно поэтому подсчёт покрытия часто используется совместно с тестами и прочим Continuous Integration: смотрим на непокрытые участки кода и либо удаляем их (как потерявшие актуальность), либо добавляем тест, который приведёт к срабатыванию нужной ветки.
Ну и в любом случае, имея детальную карту покрытия можно легко её огрубить до уровня функции, объектника, или библиотеки. А уже потом разбираться с такими крупными блоками — если из всей библиотеки ни одной функции не было вызвано, то на неё надо посмотреть повнимательнее на предмет полезности.
Здравствуйте, sergey2b, Вы писали:
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
Кроме уже предложенных, можно попробовать профилировщики. Они выдают список всех ф-ций, которые вызывались. Если список можно вывести в текстовый файл, еще лучше. Еще поискать что-то типа call graph profiler.
Вот тут что-то делают https://www.cs.sfu.ca/~wsumner/teaching/886/callgraph-profiler.html
Здравствуйте, reversecode, Вы писали:
R>если даже несколько сот многовато, для программиста >5 лет R>это проф не пригодность
Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
Ничего подобного.
Код он не сферический в вакууме. А взаимодействует с другим кодом (ОС, библиотеками и т.д.).
Даже программисту-одиночке придётся изучать документацию, а часто и реализацию того, с чем он работает.
А в командах необходимость понимать чужой код возрастает многократно.
Иначе программирование превращается в "шаманство". Когда вместо детального выяснения причин делают перебор разных вариантов, подстановку разнообразных затычек и костылей, без полного понимания сути происходящего.
Причём заметь, даже пресловутое "самое общее понимание" — оно не возникает внезапно изниоткуда. Это тысячи часов опыта. Когда глядя на код ты сразу понимаешь что и зачем. А не пережёвываешь более низкоуровневые конструкции.
Здравствуйте, sergey2b, Вы писали:
S>есть ли какая либо возможность определить какой код реально используеться в приложении
Возьми код, который ТОЧНО используется (main и далее). И подключай сорцы по сообщениям линкера. Если совсем перфекционист — в подключенном сорце комментируй всё, кроме нужной функции. А потом раскомментируй по мере продвижения.
Здравствуйте, IID, Вы писали:
IID>Код он не сферический в вакууме. А взаимодействует с другим кодом (ОС, библиотеками и т.д.). IID>Даже программисту-одиночке придётся изучать документацию, а часто и реализацию того, с чем он работает.
За документацию разговора нет. А вот реализацию приходится изучать исключительно при нехватке документации (если, конечно, не ставится целью сделать "такое же, но с перламутровыми пуговицами").
IID>А в командах необходимость понимать чужой код возрастает многократно.
Именно поэтому в командах стараются применять стандарты кодирования, без которого способность понимать чужой код многократно падает. Если бы каждому программисту была имманентно присуща способность к хорошему пониманию чужого кода, в этом не было бы особой необходимости.
IID>Причём заметь, даже пресловутое "самое общее понимание" — оно не возникает внезапно изниоткуда. Это тысячи часов опыта. Когда глядя на код ты сразу понимаешь что и зачем.
Это не только опыт, но еще и определенным образом устроенные мозги, и определенные склонности. Иначе можно скатиться и до того, что каждый писатель, способный создать качественный роман, должен, лишь глядя на чужое творение (не читая его полностью и вдумчиво), видеть все характеры, сюжетные линии, их возможные нестыковки и т.п.
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
Тут невольно вспмонилось "чука — не читатель, чукча — писатель..."
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Тут невольно вспмонилось "чука — не читатель, чукча — писатель..."
ЕМ>Если чукча напишет что-нибудь достаточно дельное, то он таки писатель, увы и ах, даже если и не читал ничего.
А тут невольно вспоминается другой афоризм — про бабушку и бороду.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
Я позволю себе слегка отклониться от прямого ответа на прямой вопрос. Нужно иметь в виду, что тот факт, что какой-либо библиотечный код не используется в каком-либо конкретном приложении, не обязательно означает, что данный код бесполезен. Ведь такова природа бибилиотек — служить хранилищем всякой всячины, более или мене полезной, которая когда-нибудь где-нибудь может пригодиться. Линкер сам разберется, что нужно взять из библиотеки для того или иного приложения. Если библиотека нормально структурирована (разбита на объектные модули), то никаких проблем с избыточным размером бинарей не возникает, как правило.
--
Не можешь достичь желаемого — пожелай достигнутого.
Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
