LINUX.ORG.RU

Только грепать diff, больше не вижу вариантов.

Я так понимаю это для лога изменений нужно? Если да, то не вижу разницы, вручную это будет делаться или автоматически. Всё равно ведь надо будет описывать изменения. В идеале всё уже должно быть описано в сообщении к коммиту, чтобы потом можно было просто засунуть выхлоп git log в changelog.

Kilte ★★★★★ ()

Есть git diff -W, покажет каждую измененную функцию целиком. А там уж думай, как вытянуть сигнатуру.

staseg ★★★★★ ()

как еще можно реализовать такое?

libclang - строишь AST до и после, ищешь функции, которые изменились.

anonymous ()
Ответ на: комментарий от staseg

Есть git diff -W, покажет каждую измененную функцию целиком. А там уж думай, как вытянуть сигнатуру.

Если изменить функцию + выше добавить новую - как он это покажет?

anonymous ()
Ответ на: комментарий от greatchina

Это как забивать шурупы свайным молотом. Но тоже вариант.

Это единственный 100% корректный вариант, который отследит и простое перемещение функции, и реальные изменения (а не форматирование, например), и правильно найдет имена функций.

anonymous ()

Говорили, что не git, так darcs умел что-то близкое.

// А вот в Smalltalk с исключительно пометодным/поклассовым подходом ко внесению изменений контроль версий как раз и работает на уровне методов-классов, а не абстрактных безликих строчек кода

yoghurt ★★★★★ ()

В git есть фильтры для разных ЯП, с помощью которых он в диффах отображает имена функций, в которых произошли ихменения. Копай в эту сторону.

annulen ★★★★★ ()
Ответ на: комментарий от anonymous

строишь AST до и после, ищешь функции, которые изменились

А как ты эти AST сравнивать собираешься? В каждой функции рекурсивно обходить все узлы, и при несовпадении любого выдавать false? А если товарищ поменял, например, макрос, который в функции использовался, или у вызываемых функций поменялись типы аругментов на ковариантные, или другой шаблон по SFINAE начал выбираться? AST может быть разной даже если код функции абсолютно идентичен, все дело в окружении

annulen ★★★★★ ()
Ответ на: комментарий от annulen

А если товарищ поменял, например, макрос, который в функции использовался

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

STUPID_FUNCTION_DECLARATION( foo )
{
}

MORE_STUPID( foo )
}

Или она сломается об #if/gcc-мы/аттрибуты и пр.

или у вызываемых функций поменялись типы аругментов на ковариантные

И тут проблемы никакой нет это отследить.

или другой шаблон по SFINAE начал выбираться?

А это вообще из другой оперы, ТС не нужен С++.

AST может быть разной даже если код функции абсолютно идентичен, все дело в окружении

Никто и не утверждал обратное. Но у тебя на руках есть все, чтоб определить - менялась таки функция или нет.

anonymous ()
Ответ на: комментарий от anonymous

Я понял, надо найти в AST все опредения функций из текущего файла и сравнивать их содержимое уже как текст

annulen ★★★★★ ()
Ответ на: комментарий от annulen

Я понял, надо найти в AST все опредения функций из текущего файла и сравнивать их содержимое уже как текст

Как самый простой и достаточно надежный вариант - да. Хотя я про него и не подумал изначально.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.