¿Qué regla específica de comparación a nivel de bits aplica **C++20** para determinar la equivalencia entre valores de punto flotante utilizados como argumentos de plantilla de no tipo, y por qué **-0.0** y **+0.0** crean instanciaciones de plantilla distintas a pesar de compararse como iguales en expresiones en tiempo de ejecución?

Respuesta a la pregunta

C++20 introdujo tipos de punto flotante como parámetros de plantilla de no tipo (NTTP) clasificándolos como tipos estructurales. De acuerdo con el estándar ([temp.type]/4), dos argumentos de plantilla de no tipo coinciden solo si son equivalentes. Para los valores de punto flotante, la equivalencia se determina por la identidad a nivel de bits en lugar de la igualdad de valores. Esto significa que dos constantes de punto flotante se consideran el mismo argumento de plantilla solo si tienen representaciones de objeto idénticas (cada bit coincide).

Por lo tanto, +0.0 y -0.0, que difieren solo en su bit de signo bajo la representación de IEEE 754, instancian plantillas distintas. De manera similar, diferentes cargas de NaN crean tipos distintos. Esto contrasta marcadamente con el comportamiento en tiempo de ejecución donde +0.0 == -0.0 evalúa como true, porque el operador de igualdad implementa la equivalencia matemática mientras que el mecanismo de plantilla requiere identidad física.

Situación de la vida real

Nos encontramos con esto al construir una biblioteca de análisis dimensional en tiempo de compilación para un motor de simulación física. Usamos NTTP de double para representar constantes físicas (como constantes gravitacionales) y queríamos especializar solucionadores para el caso teórico de masa cero (representada como 0.0). Sin embargo, algunos cálculos constexpr que evaluaban el centro de masa producían -0.0 a través de operaciones aritméticas específicas (por ejemplo, -1.0 * 0.0).

Cuando los usuarios pasaban el resultado de estos cálculos como argumento de plantilla, el compilador seleccionaba la implementación genérica en lugar de nuestra especialización ZeroMass, lo que causaba una regresión de rendimiento del 40% porque la versión genérica realizaba inversiones de matriz completas en lugar de devolver matrices de identidad.

Consideramos tres soluciones. Primero, podríamos especializar explícitamente para +0.0 y -0.0. Este enfoque garantizaba un comportamiento correcto pero duplicaba nuestra carga de mantenimiento y aún no podía manejar varias representaciones de NaN o valores que eran efectivamente cero pero tenían diferentes patrones de bits debido a errores de redondeo.

En segundo lugar, consideramos normalizar todas las entradas utilizando una función auxiliar constexpr que obligaba al bit de signo a ser cero (por ejemplo, value == 0.0 ? 0.0 : value). Esta solución era robusta para ceros pero requería macros envolventes alrededor de cada instanciación de plantilla, ensuciando la API y confundiendo a los usuarios que esperaban pasar parámetros directamente.

En tercer lugar, implementamos una capa de normalización de tipo utilizando if constexpr y std::bit_cast para canonizar valores en el punto de entrada de nuestras met funciones, tratando efectivamente todos los ceros como positivos y colapsando NaNs silenciosos a una carga canónica. Elegimos esta solución porque proporcionaba transparencia a los usuarios de la biblioteca mientras aseguraba consistencia interna.

Después de la implementación, documentamos que la biblioteca trataba todos los NTTP de punto flotante por su representación de bits. Esto resolvió los problemas de rendimiento, aunque requería que los desarrolladores fueran conscientes de que -0.0 y +0.0 eran estados de configuración distintos en el sistema de tipos.

Lo que a menudo pierden los candidatos

¿Por qué std::is_same_v<decltype(func<+0.0>()), decltype(func<-0.0>())> evalúa como falso cuando +0.0 == -0.0 es verdadero?

La instanciación de plantillas depende de la Regla de Una Definición y la coincidencia exacta de argumentos de plantilla. Cuando el compilador encuentra func<+0.0>(), hash o compara el patrón de bits del literal de punto flotante. Dado que IEEE 754 especifica que -0.0 tiene su bit de signo configurado mientras que +0.0 no, el compilador ve dos valores constantes diferentes y genera dos instanciaciones de función distintas. El operador de igualdad en tiempo de ejecución implementa la especificación de IEEE 754 que establece que los ceros firmados son iguales, pero la maquinaria de plantilla opera a nivel de representación de objeto antes de que se apliquen las semánticas en tiempo de ejecución. Los candidatos a menudo suponen que debido a que los valores son matemáticamente equivalentes, deberían producir el mismo tipo, confundiendo la semántica de valor en tiempo de ejecución con la identidad de tipo en tiempo de compilación.

¿Por qué template<float F> struct S{}; S<1.0> no compila a pesar de que 1.0 se puede convertir implícitamente a float en expresiones normales?

Para parámetros de plantilla de no tipo de tipo de punto flotante, el estándar C++20 requiere explícitamente que el argumento de plantilla tenga el mismo tipo exacto que el parámetro; las promociones y conversiones de punto flotante estándar no están permitidas ([temp.arg.nontype]/5). El literal 1.0 tiene el tipo double, no float, por lo que no puede vincularse directamente a float F. Debes usar el sufijo float: S<1.0f>. Esta restricción existe porque la mangling de plantillas y la identidad de tipo requieren una representación inequívoca sin pérdida de precisión en la conversión. Los principiantes a menudo pasan por alto esto porque las llamadas a funciones permiten la conversión, pero las plantillas realizan una coincidencia exacta de tipos antes de que se consideren las reglas de conversión.

¿Cómo afectan diferentes cargas de NaN silenciosas (qNaN) a la instanciación de plantillas cuando todas representan "no un número"?

IEEE 754 permite que los valores NaN lleven bits de carga (información de diagnóstico). Dado que la equivalencia de plantillas de C++20 utiliza la comparación a nivel de bits, dos NaNs con diferentes cargas (por ejemplo, std::numeric_limits<double>::quiet_NaN() frente al resultado de 0.0/0.0 en diferentes hardware) son argumentos de plantilla distintos. Esto puede llevar a un aumento del tamaño del código si las rutas de código instancian plantillas para múltiples patrones de bits de NaN, o a sutiles violaciones de ODR si diferentes unidades de traducción observan diferentes representaciones de NaN para lo que el programador asumió era una sola especialización. Los candidatos frecuentemente suponen que NaN es un valor singular como nullptr, pero en realidad representa una gama de patrones de bits, cada uno distinto en el sistema de plantillas.