2015-12-26 13 views
6

La domanda è abbastanza semplice.Perché std :: size_t 4 byte su sistemi a 32 bit quando unsigned long long è 8 byte su entrambi i sistemi a 32 bit e 64 bit?

Sui sistemi a 32 bit:

std::cout << sizeof(unsigned int);  //4 
std::cout << sizeof(unsigned long long); //8 
std::cout << sizeof(std::size_t);   //4 

Sui sistemi a 64 bit:

std::cout << sizeof(unsigned int);  //4 
std::cout << sizeof(unsigned long long); //8 
std::cout << sizeof(std::size_t);   //8 

ho controllato solo l'attuazione che MSVC ha, e sembra che questo:

#ifdef _WIN64 
    typedef unsigned __int64 size_t; 
#else 
    typedef unsigned int  size_t; 
#endif 

Allora perché non effettuare std::size_tunsigned long long (std::uintmax_t) su entrambi i 32 bit e 64 bit sy deriva quando lo supportano chiaramente? O mi sbaglio?

+3

size_t dovrebbe essere il tipo più efficiente che è abbastanza grande da contenere la dimensione del più grande oggetto possibile. Su un sistema a 32 bit, questo è un numero intero senza segno a 32 bit. 64 bit è meno efficiente su un sistema a 32 bit. (Anche su x86-64, 64 bit è una quantità insignificante meno efficiente di 32-bit, ma 32-bit non è abbastanza grande per le dimensioni degli oggetti di dimensione massima). Nella modalità a 32 bit, anche su una CPU a 64 bit, i 64 bit non firmati sono molto meno efficienti di 32 bit. – JSF

risposta

8

Il punto di size_t deve essere in grado di contenere la dimensione del più grande oggetto possibile. Su un sistema a 32 bit nessun oggetto può occupare più di 2 ** 32 byte, quindi è sufficiente un tipo a 32 bit.

Per utilizzare un tipo a 64 bit sarebbe uno spreco di spazio e potenzialmente più costoso in fase di esecuzione.

6

Sarebbe uno spreco inutile. Su una macchina a 32 bit hai uno spazio di indirizzi di 4 GB, quindi non puoi avere oggetti più grandi di 4 GB, quindi l'intervallo di unè perfettamente adeguato.

Problemi correlati