Парни, вопрос. В новом коде на cpp безо всякого легаси, что

лучше использовать, когда надо скопировать из одного байтового буфера в другой?
Варианты:
1. memcpy из string.h
2. std::memcpy из cstring
3. std::copy из algorithm
4. ???
?
Плюсы/минусы/подводные камни? Честно говоря, гугление выводило всё в холиварные темы на SO. Я вижу только логический подход. Поскольку string.h предоставляется со стандартной библиотекой только лишь для compatibility, я не вижу особого смысла использовать сишный memcpy в плюсовом коде, поскольку есть его стандартный плюсовый аналог без атрибута for compatibility reason.
Интересно узнать сторонние мнения.

memcpy

std::copy

По причине?

Пофиг

Того что 2 первых варианта - Си с плюсами std::copy умеет в указатели и итераторы сразу

Я написал, что нужно скопировать чар буфер из одного в другой, там просто пиксельный буфер, итераторов там, как таковых, нет.

std::copy это шаблонная функция, и она не для байтов, а в целом для всего. memcpy тоже интересная функция, компилятор прекрасно знает что она делает, и у него, дня нее множество костылей.

итератор это указатель

std::copy подходит и туда и туда (компилируясь в memcpy при наличии возможности), а с memcpy надо каждый раз цепочку рассуждений на тему "у меня тут буфер тривиально копируемых типов или нет?"

на тему компилируется в memcpy это тоже фантазии какие-то уже)

🙄 Я копирую чар буфер из одного в другой, мне не нужны итераторы в этом контексте, я просто хочу чтобы это было эффективно. И я до сих пор не понимаю почему я должен выбрать memcpy или std::copy, а не std::memcpy.

Эффективность ОДИНАКОВАЯ

Компилятор умеет упрощать std::copy в код эквивалентный memcpy

ну, берешь указатель на начало и на конец буфера, всё

это ваши домыслы, никто такого не гарантирует

у тебя итераторы как у контейнеров из стл

Нет,лучше memcpy, как раз потому что он явно говорит, копируем байты

У меня там два указателя на src и dst и size.

не, среди мемсру и стд::мемсру лучше выбрать второе

вычисли указатель на конец

Кэп.

Стикер

да, действительно, ошибся, оно в memmove ещё может: https://gcc.godbolt.org/z/3o54foznc

Вот в такой ситуации у меня и вопрос, ПОЧЕМУ выбрать одного, а не другое. Единственная причина почему не использовать сишный memcpy это потому что он предоставлен for compatibility reason. Для меня том коде это вообще лишний атрибут.

О нет memmove точно не вариант, он же дополнительный буфер использует.

А?

никто не гарантирует что оптимизации компилятора вообще в принципе что-то ускорят, но тем не менее, когда хотят получить перформанс, начинают с того чтобы их включить, а не с того чтобы ходить по коду вставляя ассемблерные вставки и заменяя std::copy на memcpy/memmove

ЧЕГО?)

::мемсру в общем случае не обязан существовать (хотя кого мы обманываем, будет) со стд::мемсру меньше неоднозначности при чтении кода

не понятно, как вы пришли от того что я сказал к необходимости асм вставок

Ну memmove же копирует всё в intermediate буфер, а только потом в dst, дабы избежать проблему пересечения буферов, разве нет?

С конца в начало копирует и все

Он избегает эту проблему по-другому, без промежуточных массивов

нет, эту проблему можно решить проще через разворот порядка копирования при пересечении (на стандартном с или с++ такого не напишешь, но кого мы опять обманываем)

Энивей это дополнительный код, который в моём случае лишний.

Стикер

Только лишь по причине, что это без атрибута provided for compatibility reason?

подскажите всё таки откуда это знание взято? меня с некоторых пор интересуют источники подобных знаний

Нет, потому что это в неймспейсе std

Не использует

Хорошо, чем тогда хуже std::copy_n?

Ничем если это тупые байты. просто memcpy может стать одной ассемблерной командой.

Не перекрываются, есть гарантия в том контексте.

тогда memmove будет работать ровно так же как memcpy (лишь проверит сначала что нет перекрытия)

memcpy - это вообще не функция, это ОПЕРАТОР ЯЗЫКА Си (ну, формально это функция, но её все воспринимают как просто оператор)

И std::copy вероятно тоже.

Почему ее воспринимают, как оператор, если это функция. И кто эти "все" ? :)

"все" это видимо все, кроме тех, кто так не делает

Все нормальные програмисты на С/С++

В случае new/delete справедливое утверждение, но memcpy это, увы, всё таки функция

а тут можно наблюдать ещё один классический приём

Все нормальные програмисты на С/С++ говорят, что memcpy - это функия. Вы точно с нормальными общаетесь ? :)

и ведь никто не признаётся, не иначе агенты ЦРУ это всё распространяют

Так вот же... https://en.cppreference.com/w/cpp/string/byte/memmove Прям в синопсисе написано

"as if" какбе прозрачно намекает, что на самом деле ваще не так, просто ведёт себя так

это детали)

Да, ты прав