Al escribir código Win32 C/C++, ¿hay alguna ventaja (por ejemplo, rendimiento?) En usar funciones específicas de Windows como lstrcpyn o CopyMemory en lugar del CRT correspondiente funciones (aparte de la portabilidad de las funciones CRT)?Funciones de Win32 API vs. sus contrapartes CRT (ej. CopyMemory vs. memcpy)
Al menos algunas funciones de CRT utilizan las funciones de Win32 internamente. Además, el CRT requiere inicialización adicional (por ejemplo, datos específicos de subprocesos para funciones como strtok) y limpieza, que es posible que no desee que suceda.
Se puede crear una aplicación Win32 llano, sin ninguna dependencia de cualquier otra cosa que incluye el CRT (al igual que lo podría crear una aplicación simple usando el NT NTDLL.DLL - creo smss.exe de Windows es un proceso de este tipo por cierto).
Habiendo dicho eso, creo que para la mayoría de las aplicaciones eso no importa.
ACTUALIZACIÓN Dado que las personas parecen estar tan enganchado en la diferencia de funciones individuales, en particular, frente a memcpyCopyMemory, me gustaría añadir que no todas las funciones de la CRT son envolturas alrededor de las de Win32. Naturalmente, algunos se pueden implementar sin ninguna ayuda de Win32 (en realidad, memcpy es un buen ejemplo para eso), mientras que otros (sensiblemente) no pueden. Algo que, creo, @Merdad insinuó en su respuesta.
Por lo tanto, aparte de la portabilidad, no creo que el rendimiento sea el siguiente mejor argumento para o contra el uso del CRT. Debe elegir lo que mejor se adapta y que normalmente será el CRT. Y no hay nada que impida usar funciones Win32 individuales (con equivalentes CRT), donde parezca adecuado.
Depende de la función y sus requisitos.
Para cosas como memcpy, no hay ningún punto cualquiera que sea para elegir las versiones específicas de Windows. Quédese con el estándar C para mantenerlo simple y portátil.
Para otras cosas como mbstowcs, es posible que tenga que usar cosas como MultiByteToWideChar en su lugar, dependiendo de la funcionalidad que necesite.
Personalmente voy por las versiones C si es posible, y luego solo uso las versiones Win32 después, porque realmente no hay motivo para escribir código específico de Windows cuando podría escribirse de forma portátil.
memset es otro buen ejemplo aquí, puede preferir SecureZeroMemory ya que está garantizado para no ser optimizado por el compilador de Windows. – Benj
@Benj: ¿Por qué el compilador optimizaría una llamada a memset? ¿Podrías por favor elaborar? –
@ Mr_C64 - Claro, el compilador podría optimizar una llamada a memset si la memoria en cuestión está en la pila y está a punto de quedar fuera del alcance.Esto está bien, excepto que si los datos son confidenciales, como una contraseña, se dejarán en el residuo de la pila y podrían investigarse más tarde. – Benj
Como ejemplo de uso de 'memcpy' frente a' CopyMemory', que los encabezados de Windows SDK definen 'CopyMemory' como una macro que invoca' RtlCopyMemory' que es una macro que invoca 'memcpy'. –
En realidad, 'memcpy',' memmove', 'memcmp',' strlen', y 'memset' están todos implementados en ntdll.dll. Por lo tanto, las funciones de CRT siguen siendo contenedores para las funciones de Win32, envoltorios para las funciones de NtDll.dll, implementables por sí solos (por ejemplo, formato y matemática) o como parte del punto de entrada. Por ejemplo, Rust no usa MSVCRT para nada excepto para matemática y el punto de entrada, e incluso eso puede cambiar pronto. – alexchandel