CRC32 не слишком труден для реализации на любом языке, это достаточно хорошо для обнаружения простого повреждения данных и когда implemted хорошим способом, это очень быстро. Однако можно также попробовать Adler32, который почти одинаково хорош как CRC32, но еще легче реализовать (и об одинаково быстром).
образец реализации CRC32 JavaScript
Или этих двух (или возможно даже обоих) доступны в Java прямо из поля.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я работаю в компании, которая разрабатывает инструменты статического анализа.
Я был бы удивлен, если бы в большинстве (если не во всех) инструментах статического анализа не было той или иной формы проверки использования заголовков. Вы можете использовать эту страницу википедии, чтобы получить список доступных инструментов, а затем отправить электронное письмо компаниям с просьбой спросить их.
Некоторые моменты, которые следует учитывать при оценке инструмента:
Для перегрузки функций , вы хотите, чтобы все заголовки, содержащие перегрузки, были видны, не только заголовок, содержащий функцию, выбранную при разрешении перегрузки:
// f1.h
void foo (char);
// f2.h
void foo (int);
// bar.cc
#include "f1.h"
#include "f2.h"
int main ()
{
foo (0); // Calls 'foo(int)' but all functions were in overload set
}
Если вы воспользуетесь методом грубой силы, сначала удалите все заголовки, а затем повторно добавьте их, пока он не скомпилируется, если сначала добавляется 'f1.h', тогда код будет компилироваться, но семантика программы была изменена.
Аналогичное правило применяется, когда у вас есть частичные и специализации. Не имеет значения, выбрана специализация или нет, вам необходимо убедиться, что все специализации видны:
// f1.h
template <typename T>
void foo (T);
// f2.h
template <>
void foo (int);
// bar.cc
#include "f1.h"
#include "f2.h"
int main ()
{
foo (0); // Calls specialization 'foo<int>(int)'
}
Что касается примера перегрузки, метод грубой силы может привести к тому, что программа все еще компилируется, но имеет другое поведение.
Другой родственный тип анализа, на который вы можете обратить внимание, - это проверка возможности прямого объявления типов. Рассмотрим следующее:
// A.h
class A { };
// foo.h
#include "A.h"
void foo (A const &);
// bar.cc
#include "foo.h"
void bar (A const & a)
{
foo (a);
}
В приведенном выше примере определение 'A' не требуется,
Насколько я знаю, нет ни одного PC-Lint), что обидно и удивительно. Я видел предложение сделать этот фрагмент псевдокода (который в основном автоматизирует ваш «кропотливый процесс»:
для каждого файла cpp
для каждого заголовка включить
закомментировать включение
скомпилируйте файл cpp
если (compile_errors)
не закомментировать заголовок
иначе
remove header include from cpp
Поместите это в ночной cron, и он должен выполнить свою работу, не допуская неиспользуемых заголовков в рассматриваемом проекте (очевидно, вы всегда можете запустить его вручную, но это займет много времени, чтобы выполнить). Проблема только в том, что отсутствие заголовка не приводит к ошибке, но по-прежнему создает код.
Я проделал это вручную, и оно того стоит в краткосрочной (О, это в долгосрочной перспективе? - Это занимает много времени) из-за сокращения времени компиляции:
Это также рекурсивный процесс - каждый файл заголовка, который остается в, нуждается в проверке, чтобы увидеть, можно ли удалить какие-либо файлы заголовков , которые он включает. Кроме того, иногда вы можете заменить форвардные объявления на заголовочные включения.
Тогда весь процесс необходимо повторять каждые несколько месяцев / год, чтобы поддерживать оставшиеся заголовки.
На самом деле, меня немного раздражают компиляторы C ++, они должны быть в состоянии сказать вам, что не нужно - компилятор Microsoft может сказать вам, когда изменение файла заголовка можно безопасно проигнорировать во время компиляции.
Взгляните на Дегидру .
С веб-сайта:
Dehydra - это легкий инструмент статического анализа общего назначения с поддержкой сценариев, способный выполнять анализ кода C ++ для конкретных приложений. В простейшем смысле Dehydra можно рассматривать как семантический инструмент grep.
Должна быть возможность создать сценарий, который проверяет неиспользуемые файлы #include.