Столкновение номеров версий для новых выпусков в связанных файлах (документация)
&a + 1 будет указывать на память сразу после последнего элемента a или, лучше сказать, после массива a, поскольку &a имеет тип int (*)[4] (указатель на массив из четырех int) , Построение такого указателя допускается стандартным, но не разыменованием. В результате вы можете использовать его для последующей арифметики.
Итак, результат *(&a + 1) не определен. Но тем не менее *(*(&a + 1) - 1) это нечто более интересное. Эффективно он оценивается до последнего элемента в a, подробное объяснение см. В https://stackoverflow.com/a/38202469/2878070 . И просто замечание - этот хак может быть заменен более читаемой и очевидной конструкцией: a[sizeof a / sizeof a[0] - 1] (конечно, его следует применять только к массивам, а не к указателям).
3 ответа
Я думаю, что стандартный способ сделать это - использовать систему ловушек Git и m4 или sed / awk для выполнения поиска / замены, как вы предлагаете. Вам просто нужен специальный токен с комментарием в каждом файле (возможно, в заголовке).
Вот ссылка на githooks и несколько страниц, написанных людьми, решающими ту же проблему:
- http://groups.google.com/group/memcached/browse_thread/thread/b02e992ede0f0e89
- http://blog.rfwatson.net/2009/06/03/automatic-version-numbering-using-git/
Оба они полагаются на сохранение номера версии в файле где-нибудь в дереве исходных текстов.
Я также наткнулся на дубль под названием 0release , который утверждает, что автоматизирует создание выпуска (и установку номеров версий).
Наконец, что касается номеров релизов, это решается в нескольких других вопросах:
Мы используем классическую систему major.minor.patch, которая применяется к кандидатам на выпуск как «тег», у нас есть сценарий, который отмечает фиксацию как номер версии, а не использует git 'объект тега'. Вся нумерация версий сделана «вручную». Это работает достаточно хорошо, потому что номер версии создается сценариями «выпуска на промежуточную стадию», которые выполняются гораздо позже в процессе разработки. Мы не беспокоимся об использовании каких-либо хуков git, потому что нам это действительно не нужно, если коммит не покидает среду разработки, тогда ему не нужен идентификатор, кроме внутреннего кода SHA.
Мы стараемся обеспечить, чтобы каждый выпуск «патча» был двоично совместим с другими версиями с тем же основным, второстепенным тегом.
Таким образом, все, что имеет тег, должно быть по крайней мере построено, но возможно или весьма вероятно, что это не будет работать в соответствии со спецификацией.
Уточнение может заключаться в том, чтобы заставить отдел контроля качества создать подписанный объект тега для чего-либо это «одобрено QA», но пока мы полагаемся на другие документы для этого.
Распространенным решением в настоящее время является вызов AC_INIT с аргументом m4_esyscmd для генерации ВЕРСИИ из git. Например, файл configure.ac autoconf содержит строки:
AC_INIT([GNU Autoconf],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-autoconf@gnu.org])
, где build-aux / git-version-gen - это простой сценарий, который вызывает git describe для генерации номера версии. (см. gnulib)
У этого подхода есть недостатки, но он может быть эффективным.