Uspecificeret adfærd ( eng. uspecificeret adfærd ) og implementeringsdefineret adfærd ( eng. implementeringsdefineret adfærd ) - adfærden af et computerprogram , som kan variere på forskellige platforme og compilere, da programmeringssprogsspecifikationen tilbyder flere gyldige muligheder for at implementere en bestemt sprogkonstruktion. I modsætning til udefineret adfærd anses et program med uspecificeret adfærd ikke for at være fejlagtig ud fra et synspunkt om overholdelse af sprogspecifikationen; med uspecificeret adfærd begrænser specifikationen normalt den mulige adfærd, selvom den ikke reducerer dem til en enkelt acceptabel.
Forskellen mellem de to er, at adfærden er implementeringsdefineret, dokumenteret og konsistent på tværs af en given processor, miljø, systemversion osv. i nødtilstand.
Programmøren bør undgå uspecificeret adfærd på steder, hvor det er kritisk for programmets resultat - for eksempel, hvis to funktioner kaldes i en uspecificeret rækkefølge, og de deler fejlretningskode, vil dette være synligt i debug-loggen , men det kan ikke være kritisk for resultatet. En programmør, der skriver til én platform, kan blive knyttet til sin egen implementering. Og hvis han skriver et program på tværs af platforme, skal han tage højde for alle rimelige tilfælde af adfærd defineret af implementeringen.
I henhold til C99 sprogstandarden ,
uspecificeret adfærd, hvor hver implementering dokumenterer, hvordan valget er truffet
[…]
3.4.3 uspecificeret adfærd
brug af en uspecificeret værdi eller anden adfærd, hvor denne internationale standard giver to eller flere muligheder og ikke stiller yderligere krav, som er valgt i noget tilfælde — ISO/IEC 9899:201x [1]I henhold til C++ sprogstandarden ,
adfærd, for en veludformet programkonstruktion og korrekte data, der afhænger af implementeringen og som hver implementering skal dokumentere.
[…]
1.3.13 uspecificeret adfærd
adfærd, for en velformet programkonstruktion og korrekte data, der afhænger af implementeringen. Implementeringen er ikke nødvendig for at dokumentere, hvilken adfærd der opstår. [Bemærk: Normalt er rækken af mulig adfærd afgrænset af denne internationale standard. ]
— ISO/IEC 14882:2003(E)I C og C++ (i modsætning til Java-sproget ) er rækkefølgen, som funktionsparametre evalueres i, uspecificeret; derfor, i programmet nedenfor, afhænger rækkefølgen, som strengene "F" og "G" udskrives i, af compileren.
#include <iostream> int f () { std :: cout << "F" << std :: endl ; retur 3 ; } intg ( ) { std :: cout << "G" << std :: endl ; retur 4 ; } int h ( int i , int j ) { returner i + j ; } int main () { returnere h ( f (), g ()); }Det klassiske eksempel på implementeringsdefineret adfærd (uspecificeret adfærd, der skal dokumenteres af implementeringer) er størrelsen af datatyper; for eksempel kan lang i forskellige compilere og operativsystemer være 32 eller 64 bit lange. Et program, der antager, at en enkelt lang altid vil passe til en pointer , vil ikke fungere korrekt på nogle platforme (for eksempel på Windows x64 ) [2] .
Her er to implementeringer af den hurtige inverse kvadratrod : Carmack - Abrash implementeringen ( Quake III ) og C++20 implementeringen fra den engelske Wikipedia:
float Q_rsqrt ( float nummer ) { lang i ; flyde x2 , y ; const float trehalvdele = 1,5F ; x2 = tal * 0,5F ; y = tal ; i = * ( lang * ) & y ; // ond floating point bit niveau hacking i = 0x5f3759df - ( i >> 1 ); // hvad fanden? y = * ( flydende * ) & i ; y = y * ( tre halvdele - ( x2 * y * y ) ); // 1. iteration // y = y * ( trehalvdele - ( x2 * y * y ) ); // 2. iteration, denne kan fjernes returnere y ; } constexpr float Q_rsqrt ( floatnummer ) noexcept _ { static_assert ( std :: numeric_limits < float >:: is_iec559 ); float const y = std :: bit_cast < float > ( 0x5f3759df - ( std :: bit_cast < std :: uint32_t > ( nummer ) >> 1 )); returner y * ( 1,5f - ( tal * 0,5f * y * y )); }Den første er lavet til Windows og 32-bit Linux, den anden er mere universel: den giver en kompileringsfejl, hvis maskinen har ikke-standard brøktyper; tager ikke lang tid at være 32-bit.