当memcpy应该足够时，为什么存在wmemcpy？

wmemcpy似乎执行与memcpy相同的操作但接受wchar_t*而不是void* 。 如果这两个代码片段应该具有相同的行为，它的存在是否合理？ 它有用吗？

 memcpy(dest, wchar_array, sizeof(wchar_array)); 

和

 wmemcpy(dest, wchar_array, sizeof(wchar_array) / sizeof(wchar_t)); 

Answer 1

除了davmac关于API对称性的答案并且不总是授予数组的大小之外，应该强调的是wmemcpy的第三个参数是wmemcpy复制的元素的数量（而不是字节）。

如果使用wchar_t对象并使用其他函数处理它们，则可能会帮助。 例如， wcslen根据wchar_t元素返回C宽字符串长度， wcschr和wcsrchr返回wchar_t * ，因此使用它们进行一些指针算法也可以使您保持元素数的“范围”。

PS如果在您的示例中暗示了最小wchar_t数组的大小，则使用wmemcpy可能会产生比您使用的sizeof(wchar_array)更优雅的代码：

 #define SIZE 40 wchar_t wchar_array[SIZE]; // ... wmemcpy(dest, wchar_array, SIZE); 

Answer 2

我猜这主要是关于API对称性，但是，它允许更容易地编写可以使用宽字符和普通字符串（由预处理器定义或类似切换）的代码。

基本上，如果您希望您的代码使用char ，则#define您的复制function为memcpy 。 对于wchar_t ，您可以将其定义为wmemcpy 。 你的size参数只是字符数（ char或wchar_t ）; 请记住，参数不一定是固定大小的数组，因此使用sizeof并不总是一个选项。

例如，Win32 API使用类似的策略：如果定义UNICODE预处理器符号，大多数函数将解析为其宽字符版本（后缀为W），否则它们将解析为“窄”字符版本（后缀为A） ; TCHAR定义为char或wchar_t ; 结果是你可以很容易地编写适用于宽字符或常规字符的代码。

当然，这绝不是必要的 ; 但是，标准C库不一定是绝对最小的。 你可以说calloc是多余的，因为你总是可以使用malloc然后使用memset ; 然而，它仍然存在。