Создавать бинарник со всеми тестами, а потом запускать его N раз по разу на каждый тест, когда можно запустить один раз и получить тот же результат — неэффективно, долго и бессмысленно.
И, главное, для чего? Просто чтобы использовать CTest?
… плюшки ...
Все перечисленные вещи есть в Catch2 или doctest. При этом, в отличие от gtest, их не нужно компилировать и линковать.
Лучшее решение, думаю, — определять, какие заголовки относятся к сторонним, а какие — к своим. И не лезть в сторонние.
Так же, как это делают с предупреждениями, когда помечают сторонние заголовки как системные.
Может если для p аналогичным образом тоже убрать auto, то у него даже достанет мощи заглянуть в реализацию p.post() и остальные предупреждения тоже уберутся :)
разговоры про «модульные тесты» в контексте многопточности вызывают только смех.
Ну посмейтесь. ¯\_(ツ)_/¯
Потому что пока что всё выглядит так, что вам указывают на то, что стрелять через головы товарищей — нехорошо, а вы отмахиваетесь и говорите что всегда так делали, а те три трупа, что на полигоне остались — это, наверное, диверсия.
Я специально предъявил анализируемый код. Каждый может взять и проверить.
То же самое с auto, кстати: довод, что это не противоречит стандарту — очень слабый. Если бы противоречило — код бы просто не скомпилировался. Описывать функцию, которая ничего не возвращает как auto — это путать читателя, как минимум.
Слово auto вместе со стрелочкой -> после аргументов функции означает, что тип будет указан после этой самой стрелочки. И это может быть void. Путаться тут негде.
P.S. А вообще — статья хорошая. Показывает, по крайней мере, почему PVS Studio имеет смысл продавать именно так, как она продаётся. Потому что вы совершили почти все «ошибки новичка», про которые тут недавно писали. То есть и любой другой человек «с улицы», скорее всего, их совершит…
Я статическими анализаторами пользуюсь регулярно. О чём упоминал в публикации.
Честно говоря, никак не отношусь.
Генерировал тем же си-мейком, но не увидел никакой разницы в положительную сторону по сравнению с make.
Отдельно от CMake не пробовал.
CTest не люблю, потому что он заставляет каждый тест оформлять в виде отдельного исполняемого файла, а это, мягко говоря, не очень удобно.
В проекте-шаблоне я использую сторонний тестовый фреймворк, так что и в статье про CTest ни слова.
Пожалуй, я наврал. Сейчас подумал и тоже вспомнил случай, когда от порядка перечисления компонент в команде target_link_libraries зависел конечный результат.
Даже если и так, то мне не известно ни одного случая, когда CMake упал бы или сделал что-то не то, что его просили.
Что, впрочем, не отменяет культуру разработки.
В каком смысле — слишком?
Создавать бинарник со всеми тестами, а потом запускать его N раз по разу на каждый тест, когда можно запустить один раз и получить тот же результат — неэффективно, долго и бессмысленно.
И, главное, для чего? Просто чтобы использовать CTest?
Все перечисленные вещи есть в Catch2 или doctest. При этом, в отличие от gtest, их не нужно компилировать и линковать.
Продолжение истории: https://habr.com/ru/post/463295/
Продолжение истории: https://habr.com/ru/post/463295/
Будет. Но не в модульных тестах, которые все вместе отрабатывают менее чем за 0,1 с.
Да. Но не в модульных тестах, которые должны проверять определённые формальные свойства, и при этом быть максимально простыми и лаконичными.
Лучшее решение, думаю, — определять, какие заголовки относятся к сторонним, а какие — к своим. И не лезть в сторонние.
Так же, как это делают с предупреждениями, когда помечают сторонние заголовки как системные.
P.S. Спасибо за адекватную реакцию.
Статью не читай, сразу комментируй.
Да, я рекламирую PVS, угу.
Пересекающихся очень мало. Все о разном поют.
Размывают — это да. Но с формальной точки зрения бесполезными таки не делают.
Не думаю, что у нас здесь есть спор. Мне просто "обидно стало" за статические анализаторы и я решил их "позащищать".
Нет, не достало, к сожалению.
Действительно, меньше ругается:
Выходит, у него ещё больше проблем с пониманием языка C++.
Добавил скриншот в раздел про многопоточность.
Сам тест находится здесь: https://gitlab.com/star-system/proxima/blob/master/test/proxima/thread/thread_pool.cpp#L94
Лишний или не лишний — дело вкуса.
Так или иначе, анализатор работает неправильно.
Ну посмейтесь.
¯\_(ツ)_/¯Я специально предъявил анализируемый код. Каждый может взять и проверить.
Слово
autoвместе со стрелочкой->после аргументов функции означает, что тип будет указан после этой самой стрелочки. И это может бытьvoid. Путаться тут негде.Я статическими анализаторами пользуюсь регулярно. О чём упоминал в публикации.
В оправдание статических анализаторов должен сказать, что:
Честно говоря, никак не отношусь.
Генерировал тем же си-мейком, но не увидел никакой разницы в положительную сторону по сравнению с
make.Отдельно от CMake не пробовал.
CTest не люблю, потому что он заставляет каждый тест оформлять в виде отдельного исполняемого файла, а это, мягко говоря, не очень удобно.
В проекте-шаблоне я использую сторонний тестовый фреймворк, так что и в статье про CTest ни слова.
Пожалуй, я наврал. Сейчас подумал и тоже вспомнил случай, когда от порядка перечисления компонент в команде
target_link_librariesзависел конечный результат.Отличная мысль, чёрт возьми.
Даже если и так, то мне не известно ни одного случая, когда CMake упал бы или сделал что-то не то, что его просили.
Что, впрочем, не отменяет культуру разработки.