Equivalenza di < limits > e < climits >
Domanda
-
È garantito che sia sempre vero:
std::numeric_limits<int>::max() == INT_MAX
Cosa dice lo standard C ++ al riguardo? Non sono riuscito a trovare alcun riferimento nello standard che lo affermi esplicitamente, ma continuo a leggere che dovrebbero essere equivalenti.
-
Che dire dei tipi C99 che non sono nello standard C ++ 98 per i compilatori che implementano sia la parte C99 (almeno
long long
) sia C ++ 98? Non sono sicuro che ci sia alcuna garanzia che ciò sia sempre vero:std::numeric_limits<unsigned long long>::max() == ULLONG_MAX
È un presupposto ragionevole?
Soluzione
La mia copia dello standard C ++ 2003 afferma che i modelli numeric_limits < > :: max ()
e min ()
restituiranno valori:
Equivalente a
CHAR_MIN, SHRT_MIN, FLT_MIN, DBL_MIN,
ecc.Equivalente a
CHAR_MAX, SHRT_MAX, FLT_MAX, DBL_MAX,
ecc
Tuttavia, quelli sono nelle note a piè di pagina. Direttive ISO / IEC Parte 3: "Le note a piè di pagina non devono contenere requisiti." Sebbene le note a piè di pagina a tabelle o figure possano essere requisiti.
Altri suggerimenti
Il primo dovrebbe essere garantito come vero: std :: numeric_limits < int > :: max () == INT_MAX
.
Tuttavia, per unsigned long long, non ci sono garanzie poiché il compilatore / le librerie non sono tenuti a supportarle. Ma ...
Se il tuo compilatore e le librerie supportano unsigned long long, dovrebbe essere uguale poiché i limiti per i tipi saranno gli stessi indipendentemente da come lo chiedi.
sì, è un presupposto ragionevole.
Ovviamente non ci sono garanzie per i tipi di dati long long in C ++, dato che i tipi di dati long long non esistono ancora in C ++. Come si comportano, se e quando esistono, dipende dal compilatore e deve essere documentato dal compilatore.
Sebbene, per quanto ne sappia, non fa parte di nessuno dei due standard, è sicuramente un presupposto ragionevole, in particolare se si dispone di compilatori della stessa suite o fornitore. Ad esempio, G ++ 4.3 utilizza semplicemente i valori #defined di < limits >
in < climits >
.