Может стоит добавить в обе статьи про UB дисклеймер: "Приведённые в статье фрагменты кода служат сугубо для демонстрации, не стоит использовать их в реальных проектах (ну, по крайней мере берите фрагменты, которые помечены как исправленный код)"?
Ну, а если серьёзно, то большое спасибо за такой развёрнутый фидбек. Очень интересный и полезный комментарий.
Пример, как было описано, сугубо синтетический и не несёт в себе не то, что близости к продовскому коду, а даже и особой осмысленности:) Как-то раз, я ревьювил смарт-контракт на Solidity и думал: "Ё моё, в этот писец бы ещё многопоточку добавить". Ну, время пришло и я реализовал что-то похожее. Интернет-банком это стало по остаточному принципу.
Спасибо за уточнение. Нулевой адрес, NULL и nullptr - это разные сущности. В комментарии выше я имел в виду нулевой адрес. Однако, справедливости ради, вы можете привести пример стандартной библиотеки, в которой макрос NULL определён не нулём?
Суть то в том, что условие заменилось и всё:) Думаю, что можно произвести бесчеловечный эксперимент: отключить оптимизацию Induction variable и увидеть тот же результат.
Вообще, разыменование нулевого указателя - вполне корректная операция. Если говорить об "исключении", то его уж точно не будет, может сработать защита операционной системы, если она предусмотрена. Оптимизатор - это такая штука, которая зачастую не знает о том, что на входе получает компилятор и даже что он сам получает на предыдущем проходе. Такова модульная структура компиляторов.
Вы забываете, что речь идёт о языке, в котором встречаются вещи и страннее. Такой кейс действительно возможен, более того, похожая ошибка когда-то была в ядре Linux для Red Hat (подробнее можно почитать тут: https://lwn.net/Articles/342330/).
Мы не отрицаем пользу виртуального наследования вообще, если оно вам помогает - это замечательно. Просто мы отказались от него, в пользу более производительного решения. Можем себе позволить)
Дерево на вариантах - это наверное очень весело. Надо будет попробовать. Вообще, по поводу ast_visit был хороший доклад моего коллеги с С++ Russia 2022. К сожалению, он ещё не вышел, но я могу поделиться слайдами. Кстати, про кейс со switch: на сколько я помню, он не очень хорошо с ним дружит, т.к. достать индекс типа в variant стандартными средствами нельзя.
Отвечая на ваш вопрос: исключения в работе мы не используем, виртуальные функции в некоторых местах есть. По приведённым бенчмаркам видно, что предложенный способ, на некоторых проектах даёт по 10-15% перфы. Если вам этого недостаточно, то возможно вы не на том языке пишете.
Интересное решение с кэшом. Как-нибудь обязательно его попробую. Из минусов можно отметить, что всё-же придётся тянуть RTTI. А так - реально крутой способ, должно быстро работать.
Видел способ, похожий на ваш в какой-то статье. Думаю, что между статической переменной и полем enum нет особой разницы, кроме незначительного понижения производительности - к статической перменной все равно придется обращаться на рантайме. В нашем случае мы можем расписать все классы в enum "руками", так что для нас это не проблема. Также, мы можем полностью отказаться от виртуальности.
В этом сообщении мы хотели акцентировать внимание именно на том, что семантика перемещения в данном случае не сработает. Ваш вариант тоже неплох и мы рассматривали что-то похожее, когда думали над этим сообщением. Отмели мы его потому-что сообщение бы разраслось и только привело к новым вопросам. Ну не имеет смысла и не имеет, и что? Бывают ситуации, когда перемещение POD-объектов вот тоже смысла не имеет, поля всё равно копируются... Пришлось бы дописывать ещё что-нибудь, уже для других внимательных пользователей. В общем, формирование сообщений для анализатора - это своя отдельная специфика, ей занимаются сразу несколько человек (в случае, с этим сообщением - это 4 человека) и его основная цель кратко и лакончино обратить внимание на проблему. А для самых пытливых людей у диагностических правил есть целая страница-описание, которая уж точно никого в заблуждение не введёт.
Спасибо за представленные проекты, при подготовке к написанию следующих статей мы обязательно обратим на них внимание. Кстати, не сказал бы, что MuditaOS не большая и не целая. Ориентировочно к концу февраля планируется ещё одна статья по ней.
Большое спасибо за фидбек. Мне кажется, что мы не очень друг друга поняли. Любая наша документация есть на русском и английском языке, например документация для диагностического правила V833: русская версия, английская версия. Вы можете увидеть версию страницы сайта на русском и английском языке, воспользовавшись этой кнопкой (на скриншоте выделенна красным цветом):
Единственное, что мы не переводим - это диагностические сообщения анализатора. Если вопрос касается их, то такой запрос, я, как и мой коллега, ответивший вам выше, вижу в первый раз. Тут, конечно, можно долго рассуждать о том, что уровень владения английским языком у подавляющего большинства программистов позволяет им понять предупреждение. Можно посетовать на то, что в языках программирования C и С++ много терминов, у которых нет аналога в русском языке. Cообщение же, в отличии от более обширной документации хочется делать кратким, ёмким и конкретным и не очень понятно, будут ли потраченные усилия востребованны. Наконец, всегда можно нажать на кнопку в плагине или гиперссылку в статье и открыть вышеупомянутую документацию, перевод которой есть. Она, зачастую позволяет прояснить все спорные моменты и недопонимания.
Дела хорошо, но, конечно, всегда есть куда расти. Несколько диагностических правил, которые сразу пришли на ум:
V828. Decreased performance. Moving an object in a return statement prevents copy elision. V833. Using 'std::move' function's with const object disables move semantics. V1017. Variable of the 'string_view' type references a temporary object, which will be removed after evaluation of an expression.
Может стоит добавить в обе статьи про UB дисклеймер: "Приведённые в статье фрагменты кода служат сугубо для демонстрации, не стоит использовать их в реальных проектах (ну, по крайней мере берите фрагменты, которые помечены как исправленный код)"?
Ну, а если серьёзно, то большое спасибо за такой развёрнутый фидбек. Очень интересный и полезный комментарий.
Пример, как было описано, сугубо синтетический и не несёт в себе не то, что близости к продовскому коду, а даже и особой осмысленности:) Как-то раз, я ревьювил смарт-контракт на Solidity и думал: "Ё моё, в этот писец бы ещё многопоточку добавить". Ну, время пришло и я реализовал что-то похожее. Интернет-банком это стало по остаточному принципу.
Спасибо за уточнение. Нулевой адрес, NULL и nullptr - это разные сущности. В комментарии выше я имел в виду нулевой адрес. Однако, справедливости ради, вы можете привести пример стандартной библиотеки, в которой макрос NULL определён не нулём?
Суть то в том, что условие заменилось и всё:)
Думаю, что можно произвести бесчеловечный эксперимент: отключить оптимизацию Induction variable и увидеть тот же результат.
Хорошее замечание, однако, вы говорите о другой, более сложной оптимизации (вроде такой: https://en.wikipedia.org/wiki/Induction_variable). Тут гораздо проще оптимизировать условие.
Однако, это, конечно, не отменяет того, что описанная вами оптимизация тут хороша и вполне может отработать.
Вообще, разыменование нулевого указателя - вполне корректная операция. Если говорить об "исключении", то его уж точно не будет, может сработать защита операционной системы, если она предусмотрена. Оптимизатор - это такая штука, которая зачастую не знает о том, что на входе получает компилятор и даже что он сам получает на предыдущем проходе. Такова модульная структура компиляторов.
Вы забываете, что речь идёт о языке, в котором встречаются вещи и страннее. Такой кейс действительно возможен, более того, похожая ошибка когда-то была в ядре Linux для Red Hat (подробнее можно почитать тут: https://lwn.net/Articles/342330/).
А почему вы atomic выкинули?
Мы не отрицаем пользу виртуального наследования вообще, если оно вам помогает - это замечательно. Просто мы отказались от него, в пользу более производительного решения. Можем себе позволить)
Дерево на вариантах - это наверное очень весело. Надо будет попробовать. Вообще, по поводу ast_visit был хороший доклад моего коллеги с С++ Russia 2022. К сожалению, он ещё не вышел, но я могу поделиться слайдами. Кстати, про кейс со switch: на сколько я помню, он не очень хорошо с ним дружит, т.к. достать индекс типа в variant стандартными средствами нельзя.
Отвечая на ваш вопрос: исключения в работе мы не используем, виртуальные функции в некоторых местах есть. По приведённым бенчмаркам видно, что предложенный способ, на некоторых проектах даёт по 10-15% перфы. Если вам этого недостаточно, то возможно вы не на том языке пишете.
Мне кажется, что вы только что придумали RTTI из std)
А как вы бы писали AST без наследования, ну, например, на С++?
Интересное решение с кэшом. Как-нибудь обязательно его попробую. Из минусов можно отметить, что всё-же придётся тянуть RTTI. А так - реально крутой способ, должно быстро работать.
Видел способ, похожий на ваш в какой-то статье. Думаю, что между статической переменной и полем enum нет особой разницы, кроме незначительного понижения производительности - к статической перменной все равно придется обращаться на рантайме. В нашем случае мы можем расписать все классы в enum "руками", так что для нас это не проблема. Также, мы можем полностью отказаться от виртуальности.
В этом сообщении мы хотели акцентировать внимание именно на том, что семантика перемещения в данном случае не сработает. Ваш вариант тоже неплох и мы рассматривали что-то похожее, когда думали над этим сообщением. Отмели мы его потому-что сообщение бы разраслось и только привело к новым вопросам. Ну не имеет смысла и не имеет, и что? Бывают ситуации, когда перемещение POD-объектов вот тоже смысла не имеет, поля всё равно копируются... Пришлось бы дописывать ещё что-нибудь, уже для других внимательных пользователей. В общем, формирование сообщений для анализатора - это своя отдельная специфика, ей занимаются сразу несколько человек (в случае, с этим сообщением - это 4 человека) и его основная цель кратко и лакончино обратить внимание на проблему. А для самых пытливых людей у диагностических правил есть целая страница-описание, которая уж точно никого в заблуждение не введёт.
Спасибо за представленные проекты, при подготовке к написанию следующих статей мы обязательно обратим на них внимание. Кстати, не сказал бы, что MuditaOS не большая и не целая. Ориентировочно к концу февраля планируется ещё одна статья по ней.
Большое спасибо за фидбек. Мне кажется, что мы не очень друг друга поняли. Любая наша документация есть на русском и английском языке, например документация для диагностического правила V833: русская версия, английская версия. Вы можете увидеть версию страницы сайта на русском и английском языке, воспользовавшись этой кнопкой (на скриншоте выделенна красным цветом):
Единственное, что мы не переводим - это диагностические сообщения анализатора. Если вопрос касается их, то такой запрос, я, как и мой коллега, ответивший вам выше, вижу в первый раз. Тут, конечно, можно долго рассуждать о том, что уровень владения английским языком у подавляющего большинства программистов позволяет им понять предупреждение. Можно посетовать на то, что в языках программирования C и С++ много терминов, у которых нет аналога в русском языке. Cообщение же, в отличии от более обширной документации хочется делать кратким, ёмким и конкретным и не очень понятно, будут ли потраченные усилия востребованны. Наконец, всегда можно нажать на кнопку в плагине или гиперссылку в статье и открыть вышеупомянутую документацию, перевод которой есть. Она, зачастую позволяет прояснить все спорные моменты и недопонимания.
Большое спасибо что ответили, всё верно:)
На этапе написания статьи я об этом не задумывался, стоило бы поменять название. Спасибо за комментарий, в следующий раз буду внимательнее
В ближайшее время таких планов нет а так, всё зависит от заинтересованности пользователей
Дела хорошо, но, конечно, всегда есть куда расти. Несколько диагностических правил, которые сразу пришли на ум:
V828. Decreased performance. Moving an object in a return statement prevents copy elision.
V833. Using 'std::move' function's with const object disables move semantics.
V1017. Variable of the 'string_view' type references a temporary object, which will be removed after evaluation of an expression.