С memcpy, пункт назначения вообще не может перекрывать источник. С memmoveним можно. Это означает, что это memmoveможет быть немного медленнее, чем memcpy, поскольку он не может делать те же предположения.
Например, memcpyвсегда можно копировать адреса снизу вверх. Если место назначения перекрывается после источника, это означает, что некоторые адреса будут перезаписаны перед копированием. memmoveобнаружит это и скопирует в другом направлении - от высокого к низкому - в этом случае. Однако проверка этого и переключение на другой (возможно, менее эффективный) алгоритм требует времени.
при использовании memcpy, как я могу гарантировать, что адреса src и dest не перекрываются? Должен ли я лично убедиться, что src и dest не перекрываются?
Олкотт,
6
@Alcott, не используйте memcpy, если вы не знаете, что они не перекрываются - вместо этого используйте memmove. Когда нет перекрытия, memmove и memcpy эквивалентны (хотя memcpy может быть очень, очень, очень немного быстрее).
bdonlan 09
Вы можете использовать ключевое слово restrict, если вы работаете с длинными массивами и хотите защитить процесс копирования. Например, если ваш метод принимает в качестве параметров массивы ввода и вывода, и вы должны убедиться, что пользователь не передает тот же адрес, что и ввод и вывод. Подробнее читайте здесь stackoverflow.com/questions/776283/…
DanielHsH 01
10
@DanielHsH 'restrict' - это обещание, которое вы даете компилятору; компилятор не применяет его. Если вы поместите параметр «ограничить» в свои аргументы и на самом деле имеют перекрытие (или, в более общем смысле, доступ к ограниченным данным из указателя, полученного из нескольких мест), поведение программы будет неопределенным, возникнут странные ошибки, и компилятор обычно не предупреждает об этом.
bdonlan
@bdonlan Это не просто обещание компилятору, это требование для вызывающей стороны. Это требование не соблюдается, но если вы его нарушите, вы не сможете пожаловаться, если получите неожиданный результат. Нарушение требования является неопределенным поведением, как и i = i++ + 1undefined; компилятор не запрещает вам писать именно этот код, но результатом этой инструкции может быть что угодно, и разные компиляторы или процессоры будут показывать здесь разные значения.
char[] str ="foo-bar";
memcpy(&str[3],&str[4],4);//might blow up
Очевидно, что теперь источник и место назначения перекрываются, мы заменяем «-bar» на «bar». Это неопределенное поведение с использованием, memcpyесли источник и место назначения перекрываются, поэтому в этом случае нам нужны случаи memmove.
@ultraman: Потому что это МОЖЕТ быть реализовано с использованием низкоуровневой сборки, которая требует, чтобы память не перекрывалась. Если это так, вы можете, например, сгенерировать сигнал или аппаратное исключение для процессора, который прерывает приложение. В документации указано, что он не обрабатывает условие, но в стандарте не указано, что произойдет, когда эти условия будут выполнены (это известно как неопределенное поведение). Неопределенное поведение может делать что угодно.
Мартин Йорк,
с gcc 4.8.2, даже memcpy также принимает перекрывающиеся указатели источника и назначения и работает нормально.
GeekyJ
4
@jagsgediya Конечно, может. Но так как memcpy задокументировано, чтобы не поддерживать это, вы не должны полагаться на это поведение, специфичное для реализации, поэтому существует memmove (). В другой версии gcc все может быть иначе. Это может быть иначе, если gcc встраивает memcpy вместо вызова memcpy () в glibc, это может быть иначе в более старой или новой версии glibc и так далее.
№
На практике кажется, что memcpy и memmove сделали то же самое. Такое глубокое неопределенное поведение.
Функция memcpy () копирует n байтов из области памяти src в область памяти dest. Области памяти не должны перекрываться. Используйте memmove (3), если области памяти перекрываются.
Основное различие между memmove()и в memcpy()том , что в буфера - временная память - используется, так что нет никакого риска дублирования. С другой стороны, данные напрямую копируются из места, указанного источником, в место, указанное адресатом . ( http://www.cplusplus.com/reference/cstring/memcpy/ )memmove()memcpy()
Рассмотрим следующие примеры:
#include<stdio.h>#include<string.h>int main (void){char string []="stackoverflow";char*first,*second;
first = string;
second = string;
puts(string);
memcpy(first+5, first,5);
puts(first);
memmove(second+5, second,5);
puts(second);return0;}
Как вы и ожидали, это распечатает:
stackoverflow
stackstacklow
stackstacklow
Но в этом примере результаты не будут такими же:
#include<stdio.h>#include<string.h>int main (void){char string []="stackoverflow";char*third,*fourth;
third = string;
fourth = string;
puts(string);
memcpy(third+5, third,7);
puts(third);
memmove(fourth+5, fourth,7);
puts(fourth);return0;}
Но похоже, что результат, который вы упомянули, перевернут!
kumar
1
Когда я запускаю ту же программу, я получаю следующий результат: stackoverflow stackstackstw stackstackstw // означает, что нет никакой разницы в выводе между memcpy и memmove
kumar
4
"это то, что в" memmove () "используется буфер - временная память;" Это не правда. он говорит «как если бы», поэтому он просто должен вести себя так, а не так, как должно быть. Это действительно актуально, поскольку большинство реализаций memmove просто выполняют замену по XOR.
dhein
2
Я не думаю, что memmove()для использования буфера требуется реализация. Он имеет полное право перемещаться на месте (при условии, что каждое чтение завершается до любой записи по тому же адресу).
Тоби Спейт
12
Предполагая, что вам придется реализовать оба варианта, реализация может выглядеть так:
void memmove (void* dst,constvoid* src,size_t count ){if((uintptr_t)src <(uintptr_t)dst){// Copy from back to front}elseif((uintptr_t)dst <(uintptr_t)src){// Copy from front to back}}void mempy (void* dst,constvoid* src,size_t count ){if((uintptr_t)src !=(uintptr_t)dst){// Copy in any way you want}}
И это должно хорошо объяснить разницу. memmoveвсегда копирует таким образом, что это все еще безопасно, если srcи dstперекрываются, тогда как memcpyпросто все равно, как говорится в документации при использовании memcpy, две области памяти не должны перекрываться.
Например, если memcpyкопии "спереди назад" и блоки памяти выровнены следующим образом
[---- src ----][---- dst ---]
копирование первого байта srcв dstуже уничтожает содержимое последних байтов srcдо того, как они были скопированы. Только копирование «назад вперед» приведет к правильным результатам.
Теперь поменяйте местами srcи dst:
[---- dst ----][---- src ---]
В этом случае безопасно копировать только «спереди назад», поскольку копирование «назад вперед» уничтожит srcего переднюю часть уже при копировании первого байта.
Возможно, вы заметили, что приведенная memmoveвыше реализация даже не проверяет, действительно ли они перекрываются, она просто проверяет их относительное положение, но только это сделает копию безопасной. Поскольку memcpyобычно используется самый быстрый способ копирования памяти в любой системе, memmoveон обычно реализуется как:
void memmove (void* dst,constvoid* src,size_t count ){if((uintptr_t)src <(uintptr_t)dst&&(uintptr_t)src + count >(uintptr_t)dst){// Copy from back to front}elseif((uintptr_t)dst <(uintptr_t)src&&(uintptr_t)dst + count >(uintptr_t)src){// Copy from front to back}else{// They don't overlap for sure
memcpy(dst, src, count);}}
Иногда, если memcpyвсегда копировать «спереди назад» или «сзади вперед», memmoveможет также использоваться memcpyв одном из случаев перекрытия, но memcpyможет даже копироваться другим способом в зависимости от того, как данные выровнены и / или сколько данных должно быть скопировано, поэтому даже если вы проверили, как memcpyкопируется в своей системе, вы не можете рассчитывать на то, что результат теста всегда будет правильным.
Что это значит для вас, когда вы решаете, в какой из них позвонить?
Если вы не знаете это наверняка srcи dstне перекрываетесь, вызывайте, memmoveпоскольку это всегда приводит к правильным результатам и обычно выполняется настолько быстро, насколько это возможно для требуемого вам варианта копирования.
Если вы знаете это наверняка srcи dstне пересекаетесь, позвоните, memcpyпоскольку не имеет значения, какой из них вы вызываете для результата, оба будут работать правильно в этом случае, но memmoveникогда не будут быстрее, чем, memcpyа если вам не повезло, это может даже будьте медленнее, так что вы можете только выиграть колл memcpy.
просто из стандарта ISO / IEC: 9899 это хорошо описано.
7.21.2.1 Функция memcpy
[...]
2 Функция memcpy копирует n символов из объекта, на который указывает s2, в объект, на который указывает s1. Если копирование происходит между перекрывающимися объектами, поведение не определено.
И
7.21.2.2 Функция memmove
[...]
2 Функция memmove копирует n символов из объекта, на который указывает s2, в объект, на который указывает s1. Копирование происходит так, как если бы n символов из объекта, на который указывает s2, сначала копируются во временный массив из n символов, который не перекрывает объекты, на которые указывают s1 и s2, а затем n символов из временного массива копируются в объект, на который указывает s1.
Какой из них я обычно использую в соответствии с вопросом, зависит от того, какая функциональность мне нужна.
В обычном тексте memcpy()не допускает s1и s2перекрытия, а не допускает memmove().
Есть два очевидных способа реализовать mempcpy(void *dest, const void *src, size_t n)(игнорируя возвращаемое значение):
for(char*p=src,*q=dest; n-->0;++p,++q)*q=*p;
char*p=src,*q=dest;while(n-->0)
q[n]=p[n];
В первой реализации копирование переходит от младших адресов к старшим, а во второй - от старших к младшим. Если копируемый диапазон перекрывается (как, например, в случае прокрутки фреймбуфера), тогда только одно направление работы является правильным, а другое будет перезаписывать места, из которых впоследствии будут считываться.
В memmove()простейшем случае реализация будет тестировать dest<src(некоторым платформо-зависимым способом) и выполнять соответствующее направление memcpy().
Код пользователя не может сделать это, конечно, потому что даже после отливки srcи dstв какой - то тип указателя бетона, они не (в целом) точек в тот же объект , и поэтому не могут быть сопоставлены. Но стандартная библиотека может иметь достаточно знаний о платформе, чтобы выполнить такое сравнение, не вызывая неопределенного поведения.
Обратите внимание, что в реальной жизни реализации имеют тенденцию быть значительно более сложными, чтобы получить максимальную производительность от более крупных передач (когда позволяет выравнивание) и / или хорошего использования кэша данных. Приведенный выше код призван максимально упростить суть.
memmove может иметь дело с перекрывающимися областями источника и назначения, в то время как memcpy не может. Среди них memcpy намного эффективнее. Так что лучше ИСПОЛЬЗУЙТЕ memcpy, если можете.
В этом ответе говорится «возможно, немного быстрее» и предоставляются количественные данные, указывающие лишь на небольшую разницу. Этот ответ утверждает, что один «намного эффективнее». Насколько эффективнее вы нашли более быстрый? BTW: Я полагаю, вы имеете в виду, memcpy()а не memcopy().
chux
Комментарий сделан на основе лекции доктора Джерри Кейна. Прошу вас послушать его лекцию в 36:00, всего 2-3 минуты хватит. И спасибо за улов. : D
Ответы:
С
memcpy
, пункт назначения вообще не может перекрывать источник. Сmemmove
ним можно. Это означает, что этоmemmove
может быть немного медленнее, чемmemcpy
, поскольку он не может делать те же предположения.Например,
memcpy
всегда можно копировать адреса снизу вверх. Если место назначения перекрывается после источника, это означает, что некоторые адреса будут перезаписаны перед копированием.memmove
обнаружит это и скопирует в другом направлении - от высокого к низкому - в этом случае. Однако проверка этого и переключение на другой (возможно, менее эффективный) алгоритм требует времени.источник
i = i++ + 1
undefined; компилятор не запрещает вам писать именно этот код, но результатом этой инструкции может быть что угодно, и разные компиляторы или процессоры будут показывать здесь разные значения.memmove
может обрабатывать перекрывающуюся память,memcpy
не может.Рассматривать
Очевидно, что теперь источник и место назначения перекрываются, мы заменяем «-bar» на «bar». Это неопределенное поведение с использованием,
memcpy
если источник и место назначения перекрываются, поэтому в этом случае нам нужны случаиmemmove
.источник
На странице руководства memcpy .
источник
Основное различие между
memmove()
и вmemcpy()
том , что в буфера - временная память - используется, так что нет никакого риска дублирования. С другой стороны, данные напрямую копируются из места, указанного источником, в место, указанное адресатом . ( http://www.cplusplus.com/reference/cstring/memcpy/ )memmove()
memcpy()
Рассмотрим следующие примеры:
Как вы и ожидали, это распечатает:
Но в этом примере результаты не будут такими же:
Вывод:
Это потому, что "memcpy ()" делает следующее:
источник
memmove()
для использования буфера требуется реализация. Он имеет полное право перемещаться на месте (при условии, что каждое чтение завершается до любой записи по тому же адресу).Предполагая, что вам придется реализовать оба варианта, реализация может выглядеть так:
И это должно хорошо объяснить разницу.
memmove
всегда копирует таким образом, что это все еще безопасно, еслиsrc
иdst
перекрываются, тогда какmemcpy
просто все равно, как говорится в документации при использованииmemcpy
, две области памяти не должны перекрываться.Например, если
memcpy
копии "спереди назад" и блоки памяти выровнены следующим образомкопирование первого байта
src
вdst
уже уничтожает содержимое последних байтовsrc
до того, как они были скопированы. Только копирование «назад вперед» приведет к правильным результатам.Теперь поменяйте местами
src
иdst
:В этом случае безопасно копировать только «спереди назад», поскольку копирование «назад вперед» уничтожит
src
его переднюю часть уже при копировании первого байта.Возможно, вы заметили, что приведенная
memmove
выше реализация даже не проверяет, действительно ли они перекрываются, она просто проверяет их относительное положение, но только это сделает копию безопасной. Посколькуmemcpy
обычно используется самый быстрый способ копирования памяти в любой системе,memmove
он обычно реализуется как:Иногда, если
memcpy
всегда копировать «спереди назад» или «сзади вперед»,memmove
может также использоватьсяmemcpy
в одном из случаев перекрытия, ноmemcpy
может даже копироваться другим способом в зависимости от того, как данные выровнены и / или сколько данных должно быть скопировано, поэтому даже если вы проверили, какmemcpy
копируется в своей системе, вы не можете рассчитывать на то, что результат теста всегда будет правильным.Что это значит для вас, когда вы решаете, в какой из них позвонить?
Если вы не знаете это наверняка
src
иdst
не перекрываетесь, вызывайте,memmove
поскольку это всегда приводит к правильным результатам и обычно выполняется настолько быстро, насколько это возможно для требуемого вам варианта копирования.Если вы знаете это наверняка
src
иdst
не пересекаетесь, позвоните,memcpy
поскольку не имеет значения, какой из них вы вызываете для результата, оба будут работать правильно в этом случае, ноmemmove
никогда не будут быстрее, чем,memcpy
а если вам не повезло, это может даже будьте медленнее, так что вы можете только выиграть коллmemcpy
.источник
Один обрабатывает перекрывающиеся пункты назначения, другой - нет.
источник
просто из стандарта ISO / IEC: 9899 это хорошо описано.
И
Какой из них я обычно использую в соответствии с вопросом, зависит от того, какая функциональность мне нужна.
В обычном тексте
memcpy()
не допускаетs1
иs2
перекрытия, а не допускаетmemmove()
.источник
Есть два очевидных способа реализовать
mempcpy(void *dest, const void *src, size_t n)
(игнорируя возвращаемое значение):В первой реализации копирование переходит от младших адресов к старшим, а во второй - от старших к младшим. Если копируемый диапазон перекрывается (как, например, в случае прокрутки фреймбуфера), тогда только одно направление работы является правильным, а другое будет перезаписывать места, из которых впоследствии будут считываться.
В
memmove()
простейшем случае реализация будет тестироватьdest<src
(некоторым платформо-зависимым способом) и выполнять соответствующее направлениеmemcpy()
.Код пользователя не может сделать это, конечно, потому что даже после отливки
src
иdst
в какой - то тип указателя бетона, они не (в целом) точек в тот же объект , и поэтому не могут быть сопоставлены. Но стандартная библиотека может иметь достаточно знаний о платформе, чтобы выполнить такое сравнение, не вызывая неопределенного поведения.Обратите внимание, что в реальной жизни реализации имеют тенденцию быть значительно более сложными, чтобы получить максимальную производительность от более крупных передач (когда позволяет выравнивание) и / или хорошего использования кэша данных. Приведенный выше код призван максимально упростить суть.
источник
memmove может иметь дело с перекрывающимися областями источника и назначения, в то время как memcpy не может. Среди них memcpy намного эффективнее. Так что лучше ИСПОЛЬЗУЙТЕ memcpy, если можете.
Ссылка: https://www.youtube.com/watch?v=Yr1YnOVG-4g Доктор Джерри Кейн, (Стэнфордская вводная лекция по системам - 7) Время: 36:00
источник
memcpy()
а неmemcopy()
.