Che cos'è size_t in C?

Mi sto confondendo con size_tin C. So che è stato restituito sizeofdall'operatore. Ma cos'è esattamente? È un tipo di dati?

Diciamo che ho un forciclo:

for(i = 0; i < some_size; i++)

Dovrei usare int i;o size_t i;?

Da Wikipedia :

Secondo lo standard ISO C del 1999 (C99), size_tè un tipo intero senza segno di almeno 16 bit (vedere sezioni 7.17 e 7.18.3).

size_tè un tipo di dati senza segno definito da diversi standard C / C ++, ad esempio lo standard C99 ISO / IEC 9899, ​​definito in stddef.h. 1 Può essere ulteriormente importato includendo stdlib.hcome questo file internamente include stddef.h.

Questo tipo viene utilizzato per rappresentare la dimensione di un oggetto. Le funzioni di libreria che accettano o restituiscono dimensioni si aspettano che siano di tipo o abbiano il tipo restituito di size_t. Inoltre, la dimensione dell'operatore basata sul compilatore più frequentemente utilizzata dovrebbe valutare un valore costante compatibile con size_t.

Come conseguenza, size_tè un tipo garantito per contenere qualsiasi indice di array.

size_tè un tipo senza segno. Pertanto, non può rappresentare alcun valore negativo (<0). Lo usi quando stai contando qualcosa e sei sicuro che non può essere negativo. Ad esempio, strlen()restituisce a size_tperché la lunghezza di una stringa deve essere almeno 0.

Nel tuo esempio, se l'indice del tuo ciclo sarà sempre maggiore di 0, potrebbe avere senso utilizzare size_to qualsiasi altro tipo di dati senza segno.

Quando usi un size_toggetto, devi assicurarti che in tutti i contesti in cui viene usato, incluso l'aritmetica, desideri valori non negativi. Ad esempio, supponiamo che tu abbia:

size_t s1 = strlen(str1);
size_t s2 = strlen(str2);

e vuoi trovare la differenza delle lunghezze di str2e str1. Non puoi fare:

int diff = s2 - s1; /* bad */

Questo perché il valore assegnato diffsarà sempre un numero positivo, anche quando s2 < s1, poiché il calcolo viene eseguito con tipi senza segno. In questo caso, a seconda del caso d'uso, potrebbe essere meglio usare int(o long long) per s1e s2.

Ci sono alcune funzioni in C / POSIX che potrebbero / dovrebbero usare size_t, ma non per ragioni storiche. Ad esempio, il secondo parametro fgetsdovrebbe idealmente essere size_t, ma lo è int.

size_t è un tipo che può contenere qualsiasi indice di array.

A seconda dell'implementazione, può essere uno dei seguenti:

unsigned char

unsigned short

unsigned int

unsigned long

unsigned long long

Ecco come size_tviene definito nella stddef.hmia macchina:

typedef unsigned long size_t;

Se sei un tipo empirico ,

echo | gcc -E -xc -include 'stddef.h' - | grep size_t

Uscita per Ubuntu 14.04 64-bit GCC 4.8:

typedef long unsigned int size_t;

Si noti che stddef.hè fornito da GCC e non glibc src/gcc/ginclude/stddef.hin GCC 4.2.

Interessanti apparizioni C99

• mallocprende size_tcome argomento, quindi determina la dimensione massima che può essere allocata.

  E poiché viene anche restituito da sizeof, penso che limiti la dimensione massima di qualsiasi array.

  Vedi anche: Qual è la dimensione massima di un array in C?

La manpage per types.h dice:

size_t deve essere un tipo intero senza segno

Poiché nessuno lo ha ancora menzionato, il significato linguistico primario di size_tè che l' sizeofoperatore restituisce un valore di quel tipo. Allo stesso modo, il significato principale di ptrdiff_tè che sottraendo un puntatore da un altro si otterrà un valore di quel tipo. Le funzioni di libreria che lo accettano lo fanno perché consentiranno a tali funzioni di lavorare con oggetti le cui dimensioni superano UINT_MAX su sistemi in cui tali oggetti potrebbero esistere, senza forzare i chiamanti a sprecare codice che passa un valore maggiore di "unsigned int" su sistemi in cui il tipo più grande basterebbe per tutti gli oggetti possibili.

Per size_tcapire perché doveva esistere e come siamo arrivati ​​qui:

In termini pragmatici, size_te ptrdiff_tsono garantiti avere 64 bit di larghezza su un'implementazione a 64 bit, 32 bit di larghezza su un'implementazione a 32 bit e così via. Non potevano forzare alcun tipo esistente a significare che, su ogni compilatore, senza rompere il codice legacy.

Un size_to ptrdiff_tnon è necessariamente uguale a un intptr_to uintptr_t. Erano diversi su alcune architetture che erano ancora in uso quando size_te ptrdiff_tfurono aggiunte allo Standard alla fine degli anni '80, e divennero obsolete quando C99 aggiunse molti nuovi tipi ma non se ne andarono ancora (come Windows a 16 bit). L'x86 in modalità protetta a 16 bit aveva una memoria segmentata in cui l'array o la struttura più grande possibile poteva avere solo 65.536 byte di dimensione, ma un farpuntatore doveva essere largo 32 bit, più largo dei registri. Su quelli, intptr_tsarebbe stato largo 32 bit ma size_teptrdiff_tpotrebbe essere largo 16 bit e inserito in un registro. E chi sapeva che tipo di sistema operativo potrebbe essere scritto in futuro? In teoria, l'architettura i386 offre un modello di segmentazione a 32 bit con puntatori a 48 bit che nessun sistema operativo ha mai effettivamente utilizzato.

Il tipo di offset della memoria non potrebbe essere longdovuto al fatto che troppi codici legacy presuppongono una longlarghezza esattamente di 32 bit. Questo presupposto è stato persino integrato nelle API UNIX e Windows. Sfortunatamente, molti altri codici legacy presumevano anche che a longfosse abbastanza largo da contenere un puntatore, un offset di file, il numero di secondi trascorsi dal 1970 e così via. POSIX ora fornisce un modo standardizzato per forzare la seconda ipotesi a essere vera invece della prima, ma nessuna delle due è una ipotesi portatile da fare.

Non potrebbe essere intperché solo una manciata di compilatori negli anni '90 ha reso intlarga 64 bit. Quindi sono diventati davvero strani mantenendo long32 bit di larghezza. La prossima revisione dello standard ha dichiarato illegale intessere più ampia di long, ma intè ancora larga 32 bit sulla maggior parte dei sistemi a 64 bit.

Non potrebbe essere long long int, che comunque è stato aggiunto in seguito, poiché è stato creato per essere largo almeno 64 bit anche su sistemi a 32 bit.

Quindi, era necessario un nuovo tipo. Anche se non lo fosse, tutti quegli altri tipi significavano qualcosa di diverso da un offset all'interno di un array o di un oggetto. E se c'era una lezione dal fiasco della migrazione da 32 a 64 bit, doveva essere specifica su quali proprietà un tipo avesse bisogno e non usarne una che significasse cose diverse in programmi diversi.

size_te intnon sono intercambiabili. Ad esempio su Linux a size_t64 bit ha una dimensione di 64 bit (ovvero sizeof(void*)) ma intè a 32 bit.

Si noti inoltre che size_tnon è firmato. Se hai bisogno di una versione firmata, ci sono ssize_tsu alcune piattaforme e sarebbe più rilevante per il tuo esempio.

Come regola generale, suggerirei di utilizzare intper la maggior parte dei casi generali e usare solo size_t/ ssize_tquando ce n'è una necessità specifica ( mmap()ad esempio).

In generale, se inizi da 0 e vai verso l'alto, usa sempre un tipo senza segno per evitare un overflow che ti porta in una situazione di valore negativo. Ciò è di fondamentale importanza, perché se i limiti dell'array risultano essere inferiori al massimo del loop, ma il massimo del loop risulta essere maggiore del massimo del tipo, verrà visualizzato un dato negativo e si potrebbe verificare un errore di segmentazione (SIGSEGV ). Quindi, in generale, non usare mai int per un ciclo che inizia da 0 e va verso l'alto. Usa un unsigned.

size_t è un tipo di dati intero senza segno. Sui sistemi che usano la libreria GNU C, questo sarà unsigned int o unsigned long int. size_t è comunemente usato per l'indicizzazione dell'array e il conteggio dei cicli.

size_t o qualsiasi tipo senza segno potrebbe essere visto usato come variabile loop poiché le variabili loop sono generalmente maggiori o uguali a 0.

Quando utilizziamo un oggetto size_t , dobbiamo assicurarci che in tutti i contesti in cui viene utilizzato, incluso l'aritmetica, desideriamo solo valori non negativi. Ad esempio, il seguente programma darebbe sicuramente il risultato inaspettato:

// C program to demonstrate that size_t or
// any unsigned int type should be used 
// carefully when used in a loop

#include<stdio.h>
int main()
{
const size_t N = 10;
int a[N];

// This is fine
for (size_t n = 0; n < N; ++n)
a[n] = n;

// But reverse cycles are tricky for unsigned 
// types as can lead to infinite loop
for (size_t n = N-1; n >= 0; --n)
printf("%d ", a[n]);
}

Output
Infinite loop and then segmentation fault

size_tè un tipo di dati intero senza segno che può assegnare solo 0 e valori di numero intero superiori a 0. Misura byte di qualsiasi dimensione dell'oggetto e restituiti sizeofdall'operatore. constè la rappresentazione della sintassi di size_t, ma senza di constte puoi eseguire il programma.

const size_t number;

size_tusato regolarmente per l'indicizzazione dell'array e il conteggio dei loop. Se il compilatore 32-bitfunziona, funzionerebbe unsigned int. Se il compilatore 64-bitfunziona, funzionerebbe unsigned long long intanche su . C'è per la dimensione massima di a size_tseconda del tipo di compilatore.

size_tgià definire il <stdio.h>file di intestazione, ma può anche definire con <stddef.h>, <stdlib.h>, <string.h>, <time.h>, <wchar.h>intestazioni.

• Esempio (con const)

#include <stdio.h>

int main()
{
    const size_t value = 200;
    size_t i;
    int arr[value];

    for (i = 0 ; i < value ; ++i)
    {
        arr[i] = i;
    }

    size_t size = sizeof(arr);
    printf("size = %zu\n", size);
}

Produzione -: size = 800

• Esempio (senza const)

#include <stdio.h>

int main()
{
    size_t value = 200;
    size_t i;
    int arr[value];

    for (i = 0 ; i < value ; ++i)
    {
        arr[i] = i;
    }

    size_t size = sizeof(arr);
    printf("size = %zu\n", size);
}

Produzione -: size = 800

Da quanto ho capito, size_tè un unsignednumero intero la cui dimensione in bit è abbastanza grande da contenere un puntatore all'architettura nativa.

Così:

sizeof(size_t) >= sizeof(void*)