Video není dostupné.
Omlouváme se.
Difference between memmove and memcpy
Vložit
- čas přidán 31. 08. 2019
- The difference between memmove and memcpy is very subtle and stands in its specifications. You can read up more on
www.cplusplus.com/reference/cs...
and
www.cplusplus.com/reference/cs...
Check out our Discord server: / discord
Implementation of memmove and memcpy where you can clearly see the difference: rextester.com/QLUB13308 Credits to Vô (from the Discord server)
A buffer is actually not a general purpose solution to the problem, since the size of this buffer would depend on the size of the overlap. Implementing a memmove in this way would need to assume dynamic allocation can happen, or a static overlapping relationship between strings; which is outside of the capabilities of the c compiler's type system.
the way memmove actually works in most implementations is that it chooses the order in which the bytes are copied depending on the structure of the overlap. If the end of the destination overlaps with the beginning of the source, you copy in the forward direction so that the first bits in the source don't get clobbered before they are captured. If the beginning of the destination overlaps with the end of the source, the copying in reverse preserve the overlapping last bits of the source. Kind of like a shift, you can think of the intermediate stages between the first and the last operation functioning as a logical buffer to 'carry' state transitions without interfering with future state transitions, and also without requiring a secondary buffer.
This is why your example worked the same way for both memmove and memcpy; memcpy is the special case memmove uses for the overlapping structure that your source and destination have. This is not reliably true with optimizations turned on though, because memcpy's type promises to the compiler that the source and destination do not overlap at all, and so a specific optimization of the operation might violate this logical relationship between memmove and memcpy. This is particularly the case for vectorization and x86 movs* instructions that might parallelize things and move things in chunks larger than a byte at a time, so order is either undefined, or operations are simply happening at a granularity larger than a single byte.
In addition, memmove and memcpy, while standard library functions, are also language primitives as far as most compilers are concerned. Several operations (like assignment to struct and array lvalues) depend on their implementation for the language to know what to do. I ran into this when doing some work where I did not want to link with libc. I still needed implementations for at least memmove and memcpy... and this is also how I ran into the the ordering stuff. I had to implement them and a buffer just didn't make sense.
Thanks for the detailed explanation!
the buffer works totally fine like the native func, I'm curious about case where the buffer doesn't work :) please share
It can only work if a static buffer will suffice (you don't care that a 10 byte and a 20 gigabyte copy/move are reserving enough space for the largest concievable move/copy), or if you are OK with the functions dynamically allocating the buffer. Neither of these is OK in the general case for something as primitive as memcopy and memmove.
omg your video finally helped me finish my project. Thank you!
Thanks You Man ! You help me a lot , hope you have a nice day
Your explanation is awsome! Thanks a lot!
Finally memmove is avoid from overlap. Good sir.please upload more videos.
8:49 If you want the compiler to no longer change anything, then -O0 may help (most C/C++ compilers have this option).
Thanks for the explaination. I was kind of wondering whether memcpy is useful or not and if not, then what I would use instead (there had tk be something).
Thank you for the video! It really help me!!!
Thank you so much. This is really helpful.
Excellent. Thank you so much.
Thanks so much!
THANK YOU
What kinds of compilers or architectures seem to be affected by this case?
We've tested most popular compilers (gcc, Visual C, cygwin and mingw) and all of them implemented both functions using a buffer. Seems like, sometimes, it's just safer to go beyond the specifications and implement it more safely.
A viewer has implemented their own versions of memcpy and memmove following exactly the specifications and you should see a difference there. The code is in the description.
How does memcpy() and memmove() will work on dynamically allocated memory ?
will same as the strings ( read only memory) or it may be different (after moving we can deallocate the dynamically allocated data)
Exactly the same way. For those functions the type of memory doesn't matter
What if I use volatile in my original string to avoid caching, will the result be any different?
memcpy doesn't work well with volatile memory. See here: stackoverflow.com/questions/54964154/is-memcpyvoid-dest-src-n-with-a-volatile-array-safe
good one !!!!!!!!!!!
what about sames exercices with string like "ßtartiñg Štöp" i mean `n * sizeof(char)` will be not okay with a string containing some multi-character character constant.
You could actually try using wchar for this: www.cplusplus.com/reference/cwchar/
I see a vlog about: "Is strcpy dangerous and what should be used instead?" they recommend me to use memcpy instead but when I call :
"char a[10] ; char b[]="zzzz" ; memcpy(a,b,strlen(b));
when I printf("%s",a"); output is zzz??????? but when I use strcpy the output is zzz
what happen which zzz"???????" why I see that?
can u help me find a good way to instead strcpy ?
It's because strcpy copies strlen(b) + 1 number of characters (it includes the NULL terminator)
Try calling it like so:
memcpy(a,b,strlen(b) + 1);
@@CodeVault Thanks💝
Thank you, CodeVault.
Working with memory, should be careful.
If,
float x=0.01;
double y=0.01;
Then why x is not equal to y ?
Because float id 4 byte and double is 8 byte.
Bitwise comparison takes adjacent 64 bits, value next 4 bytes of x must be garbage.
@@ajmalc1346 hi I want to know, overlap is disadvantage in memmove and memcpy.
Prefer to compare non-integer numbers with some tolerance whenever possible.
Find diff in source code
👍👍👍👍👍
Yay
Tu m'as fait perdre 9 minutes 14 de ma vie pour nous donner une explication FAUSSE !! FRAUDULEUX
What's false about it?
Sorry but this is a waste of time
Should've used an example that actually showed the difference, not only that but your interpretation of how memmove works is wrong, if you look at the code it doesnt use any array to store temporary values if uses if else statments and compares memory location..
It doesn't always need to use a temporary storage, that's right. Still, certain implementations do. In the description there is an example of such an implementation. Here's another one: clc-wiki.net/wiki/memmove.
@@CodeVault sorry for my reply, was a bit rude didnt mean it, bugs made me do it.
But the issue is that looking at your video it's very hard to understand the difference as you dont exactly show anything, altough the video looked very promising at the start.
You explain a bit their difference but make it very confusing and when you try to show an exaple it doesnt work like you intended which would be to show that the copy isnt properly done if they overlap using memcpy only.
No, you're right, the video was a bit rushed and didn't get the message across. I did test a few library implementations to see if there are any differences and all of them show no difference between memcpy and memmove when dealing with overlapping memory. I will be making a follow-up video to take a look at the different possible implementations of memcpy and which ones could cause issues when memory is overlapping. Thanks for the feedback!
Does not make any sense! WTH
I've put in the description code that implements the functions by the standard (kudos to a fellow viewer). You can try them and you will see the difference then.
this guy talk like indians