Why does ZeroMemory(), and similar calls exist in the Windows API when there are memset and related calls in the C standard library already? Which ones should I call? I can guess the answer is "depends". On what?
In C and C++, ZeroMemory() and memset() are the exact same thing.
/* In winnt.h */
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
/* In winbase.h */
#define ZeroMemory RtlZeroMemory
Why use ZeroMemory() then? To make it obvious. But I prefer memset() in C or C++ programs.
The actual reason is that on a different platform it might be implemented in a more efficient way than memset. Don't forget that Windows NT was designed as a highly portable operating system, it actually ran on Alpha, MIPS and Power PC. So, if the fooPC platform came out and has some assembly way to ultra-fast set memory to zero, it can be implemented without changing the high level API. This is no longer true for Windows, since now it only supports x86 and amd64 platforms, however it is still true for Windows CE.
ZeroMemory and such are part of the windows API itself. memset is part of the C standard library.
For typical userland code, I'd normally use memset (or the equivalent provided by your language of choice). If you're writing kernel code (e.g., a device driver) using something like ZeroMemory is more attractive. Since your code executes in kernel mode anyway, you don't incur the cost of a task switch to use it. Since it's already in the Windows code, you aren't carrying around extra code in your driver to duplicate what's already there. At the same time, you do incur the cost of a function call, and in the case or zeroing (especially a small block of) memory, inline code may be significantly faster, and a rep stosd doesn't take much code (in fact, setting up and using rep stosd may take less code that a function call).
Because the Windows API should be language-agnostic. It provides sufficient functionality for developers, regardless of the language they use. Of course, eventually many functions will duplicate existing functionality offered by the languages.
You should call the winapi functions (and macros) directly whenever you need a certain level of control -- compare fopen() with CreateFile() for instance. Otherwise, prefer language-specific constructs over API calls. At least, you gain more platform-independence.
Because, ZeroMemory don't require line of comment
I think one point is that the memory allocation functions should look the same in all Win32 projects, independent of the programming language. Indeed, as have been pointed out before, in C, ZeroMemory is actually memset, the C function. In Delphi,
procedure ZeroMemory(Destination: Pointer; Length: DWORD);
begin
FillChar(Destination^, Length, 0);
end;
where FillChar is the Delphi function. And so on:
procedure MoveMemory(Destination: Pointer; Source: Pointer; Length: DWORD);
begin
Move(Source^, Destination^, Length);
end;
procedure FillMemory(Destination: Pointer; Length: DWORD; Fill: Byte);
begin
FillChar(Destination^, Length, Fill);
end;
...
Actually, what you want to use is SecureZeroMemory().
An optimizing compiler can remove calls to memset(), and SecureZeroMemory() is designed to prevent this.
I used to think the ZeroMemory() calls were unnecessary until I came across this fact.
According to MSDN, ZeroMemory is a macro. It probably exists as a convenience (e.g., naming convention) or for backwards compatibility.
来源：https://stackoverflow.com/questions/3038302/why-do-zeromemory-etc-exist-when-there-are-memset-etc-already