El estándar MISRA no permite usar el operador stringify en la definición de macro. ¿Cuál es la forma alternativa de implementar el mismo concepto sin usar el operador #?
Realmente no hay alternativas directas, solo soluciones alternativas. Esta regla de asesoramiento es de la misma naturaleza que la Directiva de asesoramiento 4.9 que, para empezar, desaconseja el uso de macros similares a funciones.
Uno puede (y probablemente debe) desviarse de estas reglas/directrices, pero el punto es que hacerlo debe ser una elección informada. Deberíamos minimizar el uso de este tipo de macros y solo usarlas como último recurso. Debe motivar por qué el uso de una macro similar a una función en particular o la encadenación hace que el código sea más seguro .
Y no solo un argumento vago contra la repetición del código: la cura contra la repetición del código nunca debería ser peor que la dolencia que buscaba curar. Por ejemplo, tratar de ser "inteligente" inventando algún lenguaje de macros específico del proyecto es completamente inaceptable incluso en proyectos C normales, por lo que, naturalmente, tampoco debería hacerse en proyectos de misión crítica.
Por otro lado, cosas como las definiciones del mapa de registro, etc., se implementan muy comúnmente con macros similares a funciones y serían razones para desviarse. Hay situaciones más complejas que también pueden requerir desviaciones, siempre que pueda justificarlo.
El fundamento de la Regla 20.10 explica el propósito de la misma y lo que está tratando de prevenir... El espagueti MACRO hace que el código sea casi ilegible e imposible de mantener, y el uso de # y ## necesita una cuidadosa consideración.
Consulte también: ¿Cuáles son las aplicaciones del operador de preprocesador ## y los errores a tener en cuenta?
¿Cuál es la forma alternativa de implementar el mismo concepto sin usar el operador #?
MISRA C:2012 La regla 20.10 " No se deben usar los operadores de preprocesador # y ## " es una pauta de asesoramiento.
Esto le permite cierta flexibilidad...
Podrías (pero no lo recomendaría) desaplicar formalmente la Regla en general... permitiéndote usar # con impunidad.
Puede desactivar formalmente la regla en lugares específicos (por ejemplo, para ciertos archivos de encabezado). Esto es particularmente apropiado si el problema está relacionado con un conjunto específico de encabezados de terceros (por ejemplo, una configuración de procesador).
Puede dejar la Regla como activa y reconocer (no se requiere desviación) cada uso, habiendo verificado que es apropiado.
Podría (pero de nuevo, no lo recomiendo) reclasificar la Regla como Obligatoria y desviar formalmente cada uso.
El enfoque incorrecto sería hacer cumplir ciegamente la Regla y no usar el operador #... probablemente terminará con una sopa de macros aún peor.
Desafortunadamente, demasiados monitores de control de calidad no entienden el cumplimiento de MISRA e insisten en una aplicación del 100 %... lo que generalmente no es práctico.
MISRA le brinda opciones...
(Ver perfil para afiliación)