Здесь необходимо взять N проектов и просто проверить
Честно говоря, полезность и целесообразность исследования вызывает вопросы.
И эта надёжность очень высока.
Высока, но не достаточна. Для написания скриптов на коленке подойдет, но для чего-то серьёзного уже придется поддерживать и чуть-более сложные варианты.
Достаточно часто чтобы не пренебрегать. Конкретно анализатор без флажков компиляции жить не может, т.к. в них передается информация, без которой не провести полноценное препроцессирование и анализ.
Если уж настолько детально, то в примере под названием "У меня обычный массив" как раз красуется статический built-in массив и то, как свободная функцияstd::size вытаскивает из него размер.
В случае ручного написания С кода можно код наподобие ... уложить в 1 цикл, минимизировав обращения к памяти
Без примера такой реализации сложно сказать. Скорее всего, реализация на Си без проблем скомпилируется и на С++. Дальше останется только сравнивать ассемблерный вывод.
Вы совершенно правы. Добиться успеха можно только комбинируя методы. В дополнение к вашему примеру оставлю вариант, где без флажков не разобраться:
// main.cpp
void myFunc(){}
int main()
{
myFunc(1,2,3); // Illegal in C++, but ok in C before C23
return 12;
}
Напишем простой код, который при этом не скомпилируется в режиме С++. Положим всё это в main.cpp и соберем плюсовым компилятором в режиме Си (флаг -x c):
$ g++ -x c main.cpp
$ ./a.out
$ echo $?
12
Тоже работает. Если -x c не указывать, то получим ожидаемое:
$ g++ main.cpp
main.cpp: In function ‘int main()’:
main.cpp:5:11: error: too many arguments to function ‘void myFunc()’
5 | myFunc(1,2,3); // Illegal in C++, but ok in C before C23
P.S. Если интересно почему программа вообще собирается на Си, то у нас в документации на диагностику V1107 есть описание (она как раз ловит такие случаи).
Конечно разница есть. Только не пойму при чем тут этот вопрос. В статье я, в основном, рассказывал про std::size, а он умеет как в массивы, так и в подходящие классы.
еще раз - смотрим на заголовок статьи и читаем содержимое.
Всё ещё не могу понять суть проблемы. В заголовке "Как не надо проверять размер", в статье - "не используйте sizeof вариант". Старый метод раскритиковал, предложил варианты решения. Или я что-то упускаю?
100500 раз подтверждалось преимущество статических массивов
Преимущество в чем?
потому как в some_container::copy_from() можно понапихать всего чего угодно и получить вагон и маленькую тележку сайдэффектов
Исходя из такой логики, можно переходить сразу на Assembly. Там ещё сложнее сделать что-нибудь неявно. Да и вообще от стандартной библиотеки отказаться и все функции писать самому (со всеми вытекающими последствиями).
К сожалению, я не компетентен в заданной вами области. Поэтому не могу конкретно сказать, насколько использование какого-нибудь std::span, вместо сырых массивов, замедлит те или иные операции в обработке изображений. Если у вас есть достоверные бенчмарки - буду рад ознакомиться. Информации на эту тему в сети не много, а потому вы могли бы написать интересную статью на эту тему.
Если вы думаете что я топлю за запрет сырых указателей, built-in массивов и прочего, то вовсе нет. Мне бы тогда пришлось бросить embedded-разработку :) В общем случае я предпочту абстракции, но если уж дело дошло до оптимизаций, то тут все средства хороши. И я очень рад что С++ предоставляет настолько широкое поле для маневров.
а давайте мы изображения обрабатывать без сырых массивов
Скорее всего, использовать именно сырые массивы и указатели вас будет вынуждать какая-нибудь библиотека с Си интерфейсом. Вне её зоны ответсвенности вполне можно использовать контейнеры и различные *view.
В нашем блоге есть англоязычная версия данной статьи - для неё я сделал запрос и скриншот на английском. Результат +/- тот-же, только на сайт другой указывает.
В коде, который везёт бадью с расплавленным металлом, скорее всего, будут запрещены исключения, динамические аллокации памяти, RTTI и т.д. Написание насколько критичного ПО это целый отдельный мир с кучей ограничений, стандартов безопасности, аудитов и т.п. Не думаю, что целесообразно обсуждать данную область в рамках этой статьи.
В вашей же многобукве про это как-то скромно умалчивается
Действительно, есть такое упущение...
но почему-то таки неявно учите, что массивы в С++ - это std::xxx, а с ними нужны современные подходы, цыфровая трансформация и всякий прочий эффективный менеджмент
Не совсем так. Заманчиво просто советовать использовать средства стандартной библиотеки везде и вся, но я понимаю, что ситуации бывают разные - потому в конце есть целый раздел с подборкой вариантов в зависимости от ситуации.
В целом, не вижу ничего плохого в том чтобы новички изучали std контейнеры до build-in массивов. Да, получается не hardcore-программирование, но благодаря этому можно будет перестать изобретать неудачные велосипеды вместо стандартных реализаций. Набрался опыта - добро пожаловать на уровень "глубже".
Пока писал ответ, вспомнилась неудачная реализация кастомной функции конкатенации строк из LFortran. Мой коллега даже написал про тот случай отдельную статью.
Новички сразу заюзают нужную функцию из библиотеки
Если бы всё было так просто... Про тот-же std::size ещё нужно знать (если вы про эту функцию).
Несколько лет назад, в моём университе, всё ещё преподавали C++ как Си с классами со всеми вытекающими. Однокурсники просто не знали, что можно реализовать многие вещи гораздо проще / удобнее / безопаснее. Эта статья как раз написана в надежде, что интересующийся человек увидит современные варианты работы с плюсами вместо очередной копипасты про sizeof.
Я думаю, что отвел достаточную часть статьи на массивы, их собратьев и вычисление размеров в каждом случае. Не могли бы вы написать чего именно не хватило?
Если вопрос конкретно к заголовку "Как не надо проверять размер массива в С++", то ответ идёт через всю статью - используйте современные средства вместо sizeof((expr)) / sizeof((expr)[0]). Варианты на замену я также расписал в статье.
Изначально там был массив - потому и такой запрос. Если же перефразировать немного правильнее, и написать "контейнер", то результат будет гораздо лучше :) Беда в том, что новичку до этого ещё нужно "дойти".
Честно говоря, полезность и целесообразность исследования вызывает вопросы.
Высока, но не достаточна. Для написания скриптов на коленке подойдет, но для чего-то серьёзного уже придется поддерживать и чуть-более сложные варианты.
Достаточно часто чтобы не пренебрегать. Конкретно анализатор без флажков компиляции жить не может, т.к. в них передается информация, без которой не провести полноценное препроцессирование и анализ.
Если уж настолько детально, то в примере под названием "У меня обычный массив" как раз красуется статический built-in массив и то, как свободная функция
std::sizeвытаскивает из него размер.Без примера такой реализации сложно сказать. Скорее всего, реализация на Си без проблем скомпилируется и на С++. Дальше останется только сравнивать ассемблерный вывод.
Вы совершенно правы. Добиться успеха можно только комбинируя методы. В дополнение к вашему примеру оставлю вариант, где без флажков не разобраться:
Напишем простой код, который при этом не скомпилируется в режиме С++. Положим всё это в
main.cppи соберем плюсовым компилятором в режиме Си (флаг-x c):Тоже работает. Если
-x cне указывать, то получим ожидаемое:P.S. Если интересно почему программа вообще собирается на Си, то у нас в документации на диагностику V1107 есть описание (она как раз ловит такие случаи).
Конечно разница есть. Только не пойму при чем тут этот вопрос. В статье я, в основном, рассказывал про std::size, а он умеет как в массивы, так и в подходящие классы.
Всё ещё не могу понять суть проблемы. В заголовке "Как не надо проверять размер", в статье - "не используйте sizeof вариант". Старый метод раскритиковал, предложил варианты решения. Или я что-то упускаю?
Только в качестве fallback стратегии. Гораздо лучше получать такую информацию из команд компиляции
В прошлый раз смотрели в 2016 году. Хорошая идея перепроверить.
Преимущество в чем?
Исходя из такой логики, можно переходить сразу на Assembly. Там ещё сложнее сделать что-нибудь неявно. Да и вообще от стандартной библиотеки отказаться и все функции писать самому (со всеми вытекающими последствиями).
Внезапно, но embedded, как и разработка в целом, не зациклена на одной только обработке изображений и операциях над матрицами.
За ссылку спасибо, а вот переписывание и эксперименты над библиотекой предпочту оставить заинтересованным лицам.
Спасибо за отзыв и подмеченные недостатки. Постраюсь учесть и избежать их в будущих публикациях :)
На остальные вопросы, вроде, уже успели ответить неравнодушные комментаторы.
К сожалению, я не компетентен в заданной вами области. Поэтому не могу конкретно сказать, насколько использование какого-нибудь std::span, вместо сырых массивов, замедлит те или иные операции в обработке изображений. Если у вас есть достоверные бенчмарки - буду рад ознакомиться. Информации на эту тему в сети не много, а потому вы могли бы написать интересную статью на эту тему.
Если вы думаете что я топлю за запрет сырых указателей, built-in массивов и прочего, то вовсе нет. Мне бы тогда пришлось бросить embedded-разработку :) В общем случае я предпочту абстракции, но если уж дело дошло до оптимизаций, то тут все средства хороши. И я очень рад что С++ предоставляет настолько широкое поле для маневров.
Скорее всего, использовать именно сырые массивы и указатели вас будет вынуждать какая-нибудь библиотека с Си интерфейсом. Вне её зоны ответсвенности вполне можно использовать контейнеры и различные *view.
В нашем блоге есть англоязычная версия данной статьи - для неё я сделал запрос и скриншот на английском. Результат +/- тот-же, только на сайт другой указывает.
В коде, который везёт бадью с расплавленным металлом, скорее всего, будут запрещены исключения, динамические аллокации памяти, RTTI и т.д. Написание насколько критичного ПО это целый отдельный мир с кучей ограничений, стандартов безопасности, аудитов и т.п. Не думаю, что целесообразно обсуждать данную область в рамках этой статьи.
Действительно, есть такое упущение...
Не совсем так. Заманчиво просто советовать использовать средства стандартной библиотеки везде и вся, но я понимаю, что ситуации бывают разные - потому в конце есть целый раздел с подборкой вариантов в зависимости от ситуации.
В целом, не вижу ничего плохого в том чтобы новички изучали
stdконтейнеры до build-in массивов. Да, получается не hardcore-программирование, но благодаря этому можно будет перестать изобретать неудачные велосипеды вместо стандартных реализаций. Набрался опыта - добро пожаловать на уровень "глубже".Пока писал ответ, вспомнилась неудачная реализация кастомной функции конкатенации строк из LFortran. Мой коллега даже написал про тот случай отдельную статью.
Если бы всё было так просто... Про тот-же std::size ещё нужно знать (если вы про эту функцию).
Несколько лет назад, в моём университе, всё ещё преподавали C++ как Си с классами со всеми вытекающими. Однокурсники просто не знали, что можно реализовать многие вещи гораздо проще / удобнее / безопаснее. Эта статья как раз написана в надежде, что интересующийся человек увидит современные варианты работы с плюсами вместо очередной копипасты про
sizeof.Я думаю, что отвел достаточную часть статьи на массивы, их собратьев и вычисление размеров в каждом случае. Не могли бы вы написать чего именно не хватило?
Если вопрос конкретно к заголовку "Как не надо проверять размер массива в С++", то ответ идёт через всю статью - используйте современные средства вместо
sizeof((expr)) / sizeof((expr)[0]). Варианты на замену я также расписал в статье.Изначально там был массив - потому и такой запрос. Если же перефразировать немного правильнее, и написать "контейнер", то результат будет гораздо лучше :) Беда в том, что новичку до этого ещё нужно "дойти".