Antwoord op de vraag
C++20 introduceerde drijvende-komma types als niet-type sjabloonparameters (NTTP's) door ze te classificeren als structurele types. Volgens de standaard ([temp.type]/4) komen twee niet-type sjabloonargumenten alleen overeen als ze equivalent zijn. Voor drijvende-komma waarden wordt equivalentie bepaald door bitgewijze identiteit in plaats van waarde gelijkheid. Dit betekent dat twee drijvende-komma constanten als hetzelfde sjabloonargument worden beschouwd alleen als ze identieke objectrepresentaties hebben (elke bit komt overeen).
Bijgevolg instantiateert +0.0 en -0.0, die alleen verschillen in hun tekenbit onder IEEE 754 representatie, verschillende sjablonen. Evenzo creëren verschillende NaN payloads verschillende types. Dit contrasteert scherp met het runtime gedrag waarbij +0.0 == -0.0 evalueert tot waar, omdat de gelijkheid operator wiskundige equivalentie implementeert terwijl het sjabloonmechanisme fysieke identiteit vereist.
Situatie uit het leven
We kwamen dit tegen terwijl we een compile-tijd dimensionale analysebibliotheek voor een fysicasimulatie-engine aan het bouwen waren. We gebruikten double NTTP's om fysieke constanten (zoals zwaartekrachtsconstanten) weer te geven en wilden oplosmethoden specialiseren voor het theoretische geval van massa nul (weergegeven als 0.0). Echter, sommige constexpr berekeningen die het zwaartepunt evalueerden, produceerden -0.0 via specifieke rekenkundige bewerkingen (bijv. -1.0 * 0.0).
Toen gebruikers het resultaat van deze berekeningen als een sjabloonargument doorgeven, selecteerde de compiler de generieke implementatie in plaats van onze ZeroMass specialisatie, wat resulteerde in een prestatie regressie van 40% omdat de generieke versie volledige matrixinversies uitvoerde in plaats van identiteit matrices terug te geven.
We overwoogen drie oplossingen. Eerst konden we expliciet specialiseren voor zowel +0.0 als -0.0. Deze benadering garandeerde het juiste gedrag maar verdubbelde onze onderhoudslast en slaagde er niet in om verschillende NaN representaties of waarden die effectief nul waren maar verschillende bitpatronen hadden door afrondingsfouten te hanteren.
Ten tweede overwoogen we alle invoer te normaliseren met een constexpr hulpfunctie die het tekenbit op nul dwong (bijv. value == 0.0 ? 0.0 : value). Deze oplossing was robuust voor nullen maar vereiste wrapper macro's rond elke sjablooninstantiatie, wat de API vervuilde en gebruikers verwarring veroorzaakte die directe parameter doorgifte verwachtten.
Ten derde implementeerden we een type normalisatielaag met behulp van if constexpr en std::bit_cast om waarden bij het toegangspunt van onze meta-functies te canonicaliseren, door effectief alle nullen als positief te beschouwen en stille NaNs naar een canonieke payload samen te brengen. We kozen deze oplossing omdat het transparantie bood voor bibliotheekgebruikers terwijl het interne consistentie verzekerde.
Na implementatie documenteerden we dat de bibliotheek alle drijvende-komma NTTP's behandelde op basis van hun bitrepresentatie. Dit loste de prestatieproblemen op, hoewel het vereiste dat ontwikkelaars zich bewust waren dat -0.0 en +0.0 verschillende configuratiestaten in het typesysteem waren.
Wat kandidaten vaak missen
Waarom evalueert std::is_same_v<decltype(func<+0.0>()), decltype(func<-0.0>())> als onwaar terwijl +0.0 == -0.0 waar is?
Sjablooninstantiatie vertrouwt op de One Definition Rule en exacte sjabloonargument matching. Wanneer de compiler func<+0.0>() tegenkomt, hash of vergelijkt het het bitpatroon van de drijvende-komma literatuur. Aangezien IEEE 754 specificeert dat -0.0 zijn tekenbit ingesteld heeft terwijl +0.0 dat niet heeft, ziet de compiler twee verschillende constante waarden en genereert twee verschillende functie-instanties. De gelijkheid operator op runtime implementeert de IEEE 754 specificatie die ondertekende nullen als gelijk beschouwt, maar het sjabloonmechanisme opereert op het niveau van objectrepresentatie voordat de run-time semantiek van toepassing is. Kandidaten veronderstellen vaak dat omdat de waarden wiskundig equivalent zijn, ze hetzelfde type zouden moeten produceren, waardoor ze run-time waarde semantiek verwarren met compile-tijd type identiteit.
Waarom faalt template<float F> struct S{}; S<1.0> om te compileren ondanks dat 1.0 impliciet naar float kan worden geconverteerd in normale expressies?
Voor niet-type sjabloonparameters van drijvende-komma type vereist de C++20 standaard expliciet dat het sjabloonargument exact hetzelfde type heeft als de parameter; standaard drijvende-komma promotieregels en conversies zijn niet toegestaan ([temp.arg.nontype]/5). De literatuur 1.0 heeft het type double, niet float, dus kan het niet direct aan float F binden. Je moet de float suffix gebruiken: S<1.0f>. Deze beperking bestaat omdat sjabloon mangelen en type identiteit een ondubbelzinnige representatie zonder conversieprecisieverlies vereisen. Beginners missen dit vaak omdat functieaanroepen de conversie toestaan, maar sjablonen exacte type matching uitvoeren voordat conversieregels in overweging worden genomen.
Hoe beïnvloeden verschillende stille NaN (qNaN) payloads sjablooninstantiatie terwijl ze allemaal "geen nummer" vertegenwoordigen?
IEEE 754 staat NaN waarden toe om payload bits (diagnostische informatie) te dragen. Aangezien C++20 sjabloon gelijkheid bitgewijze vergelijking gebruikt, zijn twee NaNs met verschillende payloads (bijv. std::numeric_limits<double>::quiet_NaN() versus het resultaat van 0.0/0.0 op verschillende hardware) verschillende sjabloonargumenten. Dit kan leiden tot code groei als codepaden sjablonen instantiëren voor meerdere NaN bitpatronen, of tot subtiele ODR schendingen als verschillende vertaalunits verschillende NaN representaties waarnemen voor wat de programmeur aannam dat één specialisatie was. Kandidaten veronderstellen vaak dat NaN een enkel waarde is zoals nullptr, maar het vertegenwoordigt eigenlijk een reeks bitpatronen, elk distinct in het sjabloonsysteem.