быстрее и удобнее в использовании - да, быстрее - маловероятно, потому как там аналитически считается количество сложений и умножений с плавающей точной на одну матричную операцию, а оно хоть на фортране, хоть на це с плюсами или без плюсов одинаково. Оверхед за счет насилования кучи возникает бездумном использовании классов и нежелании использовать static вместо new.
Я понял, вы тут только понабрасывать, на все вопросы стрелки переводите на оппонента.
еще раз - смотрим на заголовок статьи и читаем содержимое.
Я искренне не понимаю, с чем вы спорите? Если вам не нужны динамические массивы, вы их не используете
это вы расскажите автору и прочим отрицателям старорежимных массивов.
std::vector понятия не имеет откуда у него там память, вставьте свой аллокатор без кучи и радуйтесь жизни.
какой хрен разница под каким соусом вызывать memcpy()? Ну кучу засирать не будет, зато скармливать аллокатору нужно что? Статический массив. Против религии же.
С чего бы это? Нет абсолютно, подчёркиваю, абсолютно ничего такого, что может произвойти в some_container::copy_from и чего не может произойти в copy(void *src, void *dst, size_t size).
Но вы же сами явно написали, да еще и в соответствии с традицией и правилами хорошего тона, что оно там внутри делает. В соответствии с теми же правилами хорошего тона в void copy() не делается никакого безобразия и делается только заявленное copy. Кроме того, функционал copy не меняется от изменений вне тела copy (как правило). А с этим вашим ООП хороший тон нифига не помогает и получаются нежданчики, когда меняешь в одном месте, а вылазит в совершенно неожиданном. Одно неловкое движение - и ты - отец, мать, сын и тёща сразу.
при использовании статических массивов никакой маллок не используется напрочь.
С другой стороны, если есть сильная необходимость использовать именно динамические массивы, то тогда, да, разницы нет. Но когда выясняется, что динамические массивы занимаются исключительно своей динамичностью с изнасилованием хипа, а на решение собственно задачи уже не хватает процессора - тогда на динамичность забивают.
Пример типовой задачи для почувствовать разницу между одним и другим я указал выше, но адептам почему-то не зашло.
и оверхеды есть только в дебаг билдах.
если вы заметили оверхед в дебаг билде на тесте, то в релизе на реальных данных с большой долей вероятности оно тоже вылезет. Все зависит от решаемой задачи.
сразу видно диванного теоретика, никогда не наступавшего на грабли с производительностью и не стоявшего раком в поле у заказчика. Попробуйте ну хотя бы потаскать иконку указателя мышки по экрану с этими вашими контейнерами и аллокаторами без вызова системных функций, тупо битмап по битмапу....
А в copy(void *src, void *dst, size_t size) нельзя, я правильно вас понял?
можно. Но возможностей для приглючений там значительно меньше
в производительности же. Вам уже было сто раз указано и на обработку изображений, и на матричные операции в контроллерах движения, 3D кадах или шуттингах и еще бог знает где. Это если не вспоминать про фрагментацию кучи, которую можно и на x64 при желании в усмерть зафрагментировать, а на более других архитектурах оно может и без желания вылезти
Исходя из такой логики, можно переходить сразу на Assembly. Там ещё сложнее сделать что-нибудь неявно.
ну так переходите, вам никто не запрещает. Только не абсолютизируйте свой локальный опыт на всё.
100500 раз проверялись тормоза при использовании динамического выделения памяти, 100500 раз подтверждалось преимущество статических массивов. Сравнительный бенч пишется левой ногой на автомате.
Если я сам пишу этот operator=, то я могу гарантировать что угодно.
опыт говорит нам, что гарантировать что либо на 100% нельзя, даже если сам. Даже самому можно поскользнуться, упасть, а потом "тут помню, тут не помню". Или каким-нить ковидом переболеть.
Оно не влияет и никогда не влияло.
опять юношеский максимализм и пионэрский задор
потому как в some_container::copy_from() можно понапихать всего чего угодно и получить вагон и маленькую тележку сайдэффектов.
Какие ваши доказательство того, что, если я, например, засуну все проверки/аллокации/копии/деаллокации в функцию resize, то это будет менее производительно чем ручной вызов всей этой мишуры?
более производительно будет не использовать всё это. И менее кучезасирательно.
resize понимаемее проверки/аллокации/копии/деаллокации, я гарантирую это.
Вы гарантируете, что когда видите A = B; то это именно присваивание, а не неведомая фигня, которая тянет за собой 100500 вызовов и конструкторов? Особенно сексуально на это смотреть в каком-нибудь отладчике, стоя раком под/над каким-нибудь устройством.
Никто и не против. Речь про то, чтобы это, образно, снаружи выглядело как void some_container::copy_from(some_container &src), а не как void copy(void *src, void *dst, size_t size).
если оно не влияет на производительность или еще что существенное
номенклатура метизов - очень большая. Шурупы-гвозди-винты - это совершенно отдельное производство. И в одном здании с каким-нибудь анодированием/чернением - это сильно вряд ли. Резка-гибка-штамповка-сварка вполне могут быть. С порошковой окраской сложнее.
Причем вы говорите в прошедшем времени, так что есть вероятность, что и этот небольшой завод накрылся
ЗЫ: практически аналогичная ситуация с подшипниками
Подразумевается, что плюсовый подход это локализовать все эти вещи в одном месте
это не плюсовой подход - это плюсовой на всю голову, ради религии, без учета соображений производительности, удобночитаемости, понимаемости кода, переносимости, безопасности и т.д.
Никто не запрещает инкапсулировать и локализовать в одном месте работу с массивами и матрицами в тупо Си-стиле
Вот странно, сколько у нас оказывается производителей электроники. Куда ни плюнь - в производителя попадешь. Я тут в магазине вчера садовые ножницы с шурупами покупал, так они сделаны в Китае. Вот странно, отечественные производители садовых ножниц и шурупов почему-то не выходят с аналогичной инициативой, хотя казалось бы - шурупы и садовые ножницы на много порядков проще в производстве, чем смартфоны, ноутбуки.
Внезапно, но embedded, как и разработка в целом, не зациклена на одной только обработке изображений и операциях над матрицами.
да ради бога. Совсем типовая задача embeded - посылать/принимать массивы/структуры данных. Хочешь - через tcp/udp, хочешь через uart или spi. В упомянутой рядом жабе это делается аналогично удалению гланд через задний проход, с соответствующими затратами ресурсов.
За ссылку спасибо, а вот переписывание и эксперименты над библиотекой предпочту оставить заинтересованным лицам.
библиотека используется вероятно на каждом сайте (и не только), а переписывать ради религиозных заблуждений никто не будет. Еще раз, каждому методу и подходу - свое место. Как лучше/производительнее/понятнее/переносимее - так и делай. Хочешь - пихай массивы внутрь контейнеров, хочешь - делай массивы контейнеров, но не надо поклоняться и возводить в абсолют один подход.
быстрее и удобнее в использовании - да, быстрее - маловероятно, потому как там аналитически считается количество сложений и умножений с плавающей точной на одну матричную операцию, а оно хоть на фортране, хоть на це с плюсами или без плюсов одинаково. Оверхед за счет насилования кучи возникает бездумном использовании классов и нежелании использовать static вместо new.
функция класса, не?
https://en.cppreference.com/w/cpp/iterator/size
ну да, надо было написать std:xxx ваше
Алиса нового поколения не умеет в тегеграм?
толку от того, что оно одно из лучших, если облачный доступ - кю три раза?
В заголовке нет std:size но есть массивы. В статье нет массивов в терминах языка C++, но есть std который в терминах C++ есть класс.
для вас тоже нет разницы между сущностями языка массив и класс?
еще раз - смотрим на заголовок статьи и читаем содержимое.
это вы расскажите автору и прочим отрицателям старорежимных массивов.
какой хрен разница под каким соусом вызывать memcpy()? Ну кучу засирать не будет, зато скармливать аллокатору нужно что? Статический массив. Против религии же.
Но вы же сами явно написали, да еще и в соответствии с традицией и правилами хорошего тона, что оно там внутри делает. В соответствии с теми же правилами хорошего тона в void copy() не делается никакого безобразия и делается только заявленное copy. Кроме того, функционал copy не меняется от изменений вне тела copy (как правило). А с этим вашим ООП хороший тон нифига не помогает и получаются нежданчики, когда меняешь в одном месте, а вылазит в совершенно неожиданном. Одно неловкое движение - и ты - отец, мать, сын и тёща сразу.
при использовании статических массивов никакой маллок не используется напрочь.
С другой стороны, если есть сильная необходимость использовать именно динамические массивы, то тогда, да, разницы нет. Но когда выясняется, что динамические массивы занимаются исключительно своей динамичностью с изнасилованием хипа, а на решение собственно задачи уже не хватает процессора - тогда на динамичность забивают.
Пример типовой задачи для почувствовать разницу между одним и другим я указал выше, но адептам почему-то не зашло.
если вы заметили оверхед в дебаг билде на тесте, то в релизе на реальных данных с большой долей вероятности оно тоже вылезет. Все зависит от решаемой задачи.
это были показательные выступления. Сначала надо было поставить фундамент
сразу видно диванного теоретика, никогда не наступавшего на грабли с производительностью и не стоявшего раком в поле у заказчика. Попробуйте ну хотя бы потаскать иконку указателя мышки по экрану с этими вашими контейнерами и аллокаторами без вызова системных функций, тупо битмап по битмапу....
можно. Но возможностей для приглючений там значительно меньше
в производительности же. Вам уже было сто раз указано и на обработку изображений, и на матричные операции в контроллерах движения, 3D кадах или шуттингах и еще бог знает где. Это если не вспоминать про фрагментацию кучи, которую можно и на x64 при желании в усмерть зафрагментировать, а на более других архитектурах оно может и без желания вылезти
ну так переходите, вам никто не запрещает. Только не абсолютизируйте свой локальный опыт на всё.
100500 раз проверялись тормоза при использовании динамического выделения памяти, 100500 раз подтверждалось преимущество статических массивов. Сравнительный бенч пишется левой ногой на автомате.
опыт говорит нам, что гарантировать что либо на 100% нельзя, даже если сам. Даже самому можно поскользнуться, упасть, а потом "тут помню, тут не помню". Или каким-нить ковидом переболеть.
опять юношеский максимализм и пионэрский задор
потому как в
some_container::copy_from() можно понапихать всего чего угодно и получить вагон и маленькую тележку сайдэффектов..
(Д, Ч или И): тема импортозамещения не раскрыта. И краски должны быть Урюпинского завода резино-технических изделий.
более производительно будет не использовать всё это. И менее кучезасирательно.
Вы гарантируете, что когда видите A = B; то это именно присваивание, а не неведомая фигня, которая тянет за собой 100500 вызовов и конструкторов? Особенно сексуально на это смотреть в каком-нибудь отладчике, стоя раком под/над каким-нибудь устройством.
если оно не влияет на производительность или еще что существенное
номенклатура метизов - очень большая. Шурупы-гвозди-винты - это совершенно отдельное производство. И в одном здании с каким-нибудь анодированием/чернением - это сильно вряд ли. Резка-гибка-штамповка-сварка вполне могут быть. С порошковой окраской сложнее.
Причем вы говорите в прошедшем времени, так что есть вероятность, что и этот небольшой завод накрылся
ЗЫ: практически аналогичная ситуация с подшипниками
редкое оно для тех, кто не пользуется.
это не плюсовой подход - это плюсовой на всю голову, ради религии, без учета соображений производительности, удобночитаемости, понимаемости кода, переносимости, безопасности и т.д.
Никто не запрещает инкапсулировать и локализовать в одном месте работу с массивами и матрицами в тупо Си-стиле
а других нет. Есть у которых на упаковке честно написан производитель, а есть аналогичные вышеназванным отечественные производители этикеток.
ЗЫ:Есть еще очечественные шуруповёрты. Особенно выделятся даже на общем фоне Интерскол. Рекомендую
Вот странно, сколько у нас оказывается производителей электроники. Куда ни плюнь - в производителя попадешь.
Я тут в магазине вчера садовые ножницы с шурупами покупал, так они сделаны в Китае. Вот странно, отечественные производители садовых ножниц и шурупов почему-то не выходят с аналогичной инициативой, хотя казалось бы - шурупы и садовые ножницы на много порядков проще в производстве, чем смартфоны, ноутбуки.
да ради бога. Совсем типовая задача embeded - посылать/принимать массивы/структуры данных. Хочешь - через tcp/udp, хочешь через uart или spi. В упомянутой рядом жабе это делается аналогично удалению гланд через задний проход, с соответствующими затратами ресурсов.
библиотека используется вероятно на каждом сайте (и не только), а переписывать ради религиозных заблуждений никто не будет. Еще раз, каждому методу и подходу - свое место. Как лучше/производительнее/понятнее/переносимее - так и делай. Хочешь - пихай массивы внутрь контейнеров, хочешь - делай массивы контейнеров, но не надо поклоняться и возводить в абсолют один подход.