Así que he sumergido mis pies en las anotaciones de código fuente para C++, pero descubrí que hay muchas maneras de llegar a Roma, por así decirlo.Anotaciones de SAL, ¿cuál usar?
Ejemplos:
__in
_In_
[Pre(FormatString(Style="printf")] LPCSTR format
¿Existe una -Microsoft-manera de hacer esto?
Microsoft ha presentado un nuevo estándar SAL (SAL 2.0) comenzando con Windows 8 . SAL 2.0 utiliza el estilo de subrayado único de las anotaciones, como _In_opt_among others. Por lo tanto, para todo código nuevo, la mejor práctica sería seguir el estilo SAL 2.0, como slides de la exhibición de Microsoft.
Para un código anterior, la regla general de "mantener la coherencia" parece ser la mejor opción, pero si se siente inclinado a actualizar todas sus anotaciones, siga de nuevo el estilo SAL 2.0.
-
- SAL 2.0 en realidad ha existido desde 2010 (comprobar la fecha de la presentación vinculada), pero no ha sido apoyado oficialmente el exterior hasta que Windows 8, a lo mejor de mi conocimiento.
VS2010 usa ambos sabores SAL. La SAL declspec más antigua para la API de Windows y la SAL de atributo más nueva para la CRT. – arx
, porque las anotaciones de Sal es un metalenguaje que puede ayudar a herramientas de análisis estático para comprobar el por error en tiempo de compilación, yo creo que puede ser compilador dependiente (para los controles complejos, al menos hasta cierto punto) Por lo que podría no tener una sola vía para todos ellos, pero la transición de uno a otro no es demasiado complicada
SAL podría tener sentido para C, no para C++. Pero tenga en cuenta que Microsoft incluso equivocó las anotaciones de 'MessageBox'. Esto significa que SAL es peor que basura inservible: agrega una extrema verbosidad que ralentiza a los programadores, y la poca información que transmite es a menudo incorrecta (como lo ilustra mi ejemplo), lo que no solo ralentiza a los programadores sino que los engaña activamente. Así que incluso para C, diría que es bastante * contraproducente * usar SAL. ** ¡Solo diga NO! ** –
@ Cheersandhth.-Alf No puedo hablar por el código de usuario, pero SAL en realidad es bastante beneficioso para los conductores. Particularmente las anotaciones '_IRQL' – brc
@brc: uhm, lo miré. aparte de la pregunta "¿sería SAL la única forma de lograr garantías?" se ve horriblemente compleja, mientras que los niveles de solicitud de interrupción en sí mismos son algo simple. por lo que me recuerda mucho al esquema de complejidad añadida de "apartamento" de Microsoft para enhebrar en COM. muchas personas pensaron que era significativo. muchas personas aún piensan, p. 'WinMain' (recién agregado, complejidad sin sentido contraproducente) es una buena idea. entonces, sospecho fuertemente que ese es el caso también para las anotaciones de SAL _IRCL: que simplemente están agregando complejidad y ofuscación innecesariamente. –