Pull to refresh

Comments 8

Тавтологические условия в if'ах в шаблонном коде. Это полностью нормально, является распространённой практикой и стилем кода.

Можно про эту часть чуть подробнее?
Самый простой пример:

template <typename T>
void f(T x)
{
    if (x < 0)  /// Код будет полностью удалён, если x - unsigned.
    {
        ...
    }
    ...
}
...

int x;
f(x);

unsigned y;
f(y);


Реальный пример из практики:

github.com/yandex/ClickHouse/blob/ff1598c8d12970c9bb76d3f0fd6bb8a22471b7ae/dbms/src/Interpreters/Aggregator.cpp#L596

Смотрите на no_more_keys и Method::no_consecutive_keys_optimization.
Это всё bool, известный на этапе компиляции.

В C++17 это можно написать более явно с помощью if constexpr, впрочем область применения if constexpr больше.

Кстати, в некоторых случаях для достижения такого же эффекта даже не обязательно использовать шаблоны. Можно передать обычный параметр в функцию, понадеясь на то, что компилятор будет достаточно умён, чтобы применить оптимизацию — клонирование функций после constant propagation (см. параметр -fipa-cp-clone в gcc, входит в -O3).
Clang-Tidy отличается от Clang static analyzer (также известного под названием scan-build) наличием проверок стиля.

Чуть разверну. Clang-Tidy включает в себя Clang Static Analyzer (также известного как clang --analyze, как scan-build и под видом менюшки Product->Analyze в Xcode и Analyze->Clang Static Analyzer в QtCreator) посредством clang-tidy -checks=clang-analyzer-* и дополняет его собственными проверками, как стилистическими, так и несложным bug-finding-ом на уровне синтаксиса.


Я проспал момент, почему эти два анализатора вообще существуют отдельно, но сейчас у них сильно разная "философия" (Analyzer старается, насколько это возможно, искать только "реальные баги" и таким образом не сильно отвлекать разработчиков, а Tidy собирает под себя все мыслимые и немыслимые стилистические проверки) и немного разные фичи (Analyzer никак не может включить в себя проверки из Tidy — только наоборот; у Tidy мало интеграции с известными IDE, зато есть приятные fixit-ы; а в собственных проверках Tidy не используется движок "символьного выполнения" программы, на котором в Analyzer'е реализованы его самые хитрые и уважаемые проверки).

Спасибо! Я никак не мог понять, почему появилось два инструмента, и документации, где было бы об этом написано, не нашёл.
Clang Static Analyzer — часть Clang. Clang-Tidy — входит в clang-tools-extra, т. е. это независимый исполняемый файл. Исторически над Clang Static Analyzer в основном работал Apple, над Clang-Tidy — Google. Так же Clang-Tidy поглотил Clang-modernize. Кроме этого есть ещё предупреждения Clang. Но очень не хватает координации, для того, чтобы определить, какая функциональность где должна находиться.
А метрика у вас как раз ведь на ClickHouse работает?

Когда почините глюки с запросом больших колличеств статистических данных? Глюк очень просто воспроизвести — переходим в метрику, выбираем детализацию по дням, а затем период статистики в пару лет и… Вуаля! Вместо данных шляпа. Хотя иногда почему-то отрабатывает нормально. Похоже в случаях, когда до первого запроса большого периода использовалась детализация «по неделям», но не уверен.

Давно уже писал об этой проблеме, её игнорируют. Раньше, правда, ещё хуже было — после такой манипуляции метрика вообще переставала нормально данные по любым периодам отображать, приходилось заходить заново, и то не всегда помогало. В общем, если почините, будет совсем круто.

В качестве немного костыльного решения, предлагаю при слишком большом периоде автоматически уменьшать доступную детализацию до «недели».

Возможно совпадение, но вроде бы стало работать чуть лучше как раз примерно в то же время что и вышла статья, где вас проверяли в PVS-Studio =)
А метрика у вас как раз ведь на ClickHouse работает?

Да.

Когда почините глюки с запросом больших колличеств статистических данных? Глюк очень просто воспроизвести — переходим в метрику, выбираем детализацию по дням, а затем период статистики в пару лет и… Вуаля! Вместо данных шляпа. Хотя иногда почему-то отрабатывает нормально. Похоже в случаях, когда до первого запроса большого периода использовалась детализация «по неделям», но не уверен.

Не могу подробно прокомментировать конкретно вашу проблему. Если коллеги из Метрики найдут ваше обращение в support, подскажут номер счётчика, то мы сможем поискать медленные запросы в query_log.

Пока у меня только есть некоторые догадки — например, я знаю, что несколько отчётов плохо работают из-за cache словарей из MySQL (при этом для MySQL используется слабый кластер без SSD) — для решения проблемы мы реализовали словари из shared library, которые идут напрямую в YT. Но эта возможность ещё не используется. Надеюсь, что станет лучше.

Возможно совпадение, но вроде бы стало работать чуть лучше как раз примерно в то же время что и вышла статья, где вас проверяли в PVS-Studio =)

Это никак не связано. Впрочем я буду рад, если больше людей будут изучать и проверять наш код.
Sign up to leave a comment.