Nel cross-platform di oggi ++ (o C) C mondo che abbiamo :

Data model  | short |   int |   long | long long | pointers/size_t  | Sample operating systems
... 
LLP64/IL32P64   16      32      32     64           64                Microsoft Windows (x86-64 and IA-64)
LP64/I32LP64    16      32      64     64           64                Most Unix and Unix-like systems, e.g. Solaris, Linux, BSD, and OS X; z/OS
...

Ciò che significa oggi, è che per qualsiasi numero intero "comune" (firmato), intsarà sufficiente e può ancora essere usato come tipo intero predefinito quando si scrive il codice dell'applicazione C ++. Inoltre, per gli attuali scopi pratici, avrà una dimensione coerente su tutte le piattaforme.

Se un caso d'uso richiede almeno 64 bit, oggi possiamo usarlo long long, sebbene possibilmente usare uno dei tipi che specificano il testimone o il __int64tipo potrebbe avere più senso.

Questo lascia longa metà e stiamo prendendo in considerazione l'idea di vietare l'utilizzo del longnostro codice dell'applicazione .

Questo avrebbe senso , o esiste un caso per l'utilizzo longnel moderno codice C ++ (o C) che deve essere eseguito su più piattaforme? (piattaforma essendo desktop, dispositivi mobili, ma non cose come microcontrollori, DSP ecc.)

Link di sfondo forse interessanti:

• Qual è lo standard C ++ che indica la dimensione di int, long type?
• Perché il team Win64 ha scelto il modello LLP64?
• Modelli di programmazione a 64 bit: perché LP64? (un po 'invecchiato)
• È longgarantito che sia almeno 32 bit? (Questo affronta la discussione di commento sotto. Risposta .)

L'unico motivo che vorrei usare longoggi è quando si chiama o si implementa un'interfaccia esterna che lo utilizza.

Come dici nel tuo post, short e int hanno caratteristiche ragionevolmente stabili su tutte le principali piattaforme desktop / server / mobili di oggi e non vedo alcun motivo per cambiare nel prossimo futuro. Quindi vedo poche ragioni per evitarle in generale.

longd'altra parte è un casino. Su tutti i sistemi a 32 bit sono consapevole che aveva le seguenti caratteristiche.

1. Aveva esattamente 32 bit di dimensione.
2. Aveva le stesse dimensioni di un indirizzo di memoria.
3. Aveva le stesse dimensioni della più grande unità di dati che poteva essere conservata in un registro normale e lavorare con un'unica istruzione.

Grandi quantità di codice sono state scritte sulla base di una o più di queste caratteristiche. Tuttavia con il passaggio a 64 bit non è stato possibile preservarli tutti. Le piattaforme simili a Unix hanno optato per LP64 che ha conservato le caratteristiche 2 e 3 al costo della caratteristica 1. Win64 ha optato per LLP64 che ha conservato la caratteristica 1 al costo delle caratteristiche 2 e 3. Il risultato è che non puoi più fare affidamento su nessuna di quelle caratteristiche e che l'IMO lascia poche ragioni per l'uso long.

Se si desidera un tipo di dimensioni esattamente a 32 bit, è necessario utilizzare int32_t.

Se vuoi un tipo che abbia le stesse dimensioni di un puntatore, dovresti usare intptr_t(o meglio uintptr_t).

Se si desidera un tipo che è l'elemento più grande su cui è possibile lavorare in un singolo registro / istruzione, purtroppo non credo che lo standard ne preveda uno. size_tdovrebbe essere proprio sulle piattaforme più comuni ma non su x32 .

PS

Non mi preoccuperei dei tipi "veloce" o "minimo". I tipi "minimi" contano solo se ti preoccupi della portabilità per oscurare davvero architetture dove CHAR_BIT != 8. La dimensione dei tipi "veloci" in pratica sembra essere piuttosto arbitraria. Linux sembra renderli almeno della stessa dimensione del puntatore, che è stupido su piattaforme a 64 bit con supporto rapido a 32 bit come x86-64 e arm64. IIRC iOS li rende il più piccolo possibile. Non sono sicuro di cosa facciano altri sistemi.

PPS

Un motivo da usare unsigned long(ma non semplice long) è perché è garantito per avere un comportamento modulo. Sfortunatamente a causa delle regole di promozione sbagliate di C tipi non firmati più piccoli di quelli intche non hanno un comportamento modulo.

Oggi su tutte le piattaforme principali ha uint32_tle stesse dimensioni o è più grande di int e quindi ha un comportamento modulo. Tuttavia ci sono stati storicamente e teoricamente potrebbe esserci nelle piattaforme future dove intè a 64 bit e quindi uint32_tnon ha un comportamento modulo.

Personalmente direi che è meglio entrare nell'abitudine di forzare il comportamento del modulo usando "1u *" o "0u +" all'inizio delle equazioni in quanto funzionerà per qualsiasi dimensione di tipo senza segno.

Come accennato nella tua domanda, il software moderno riguarda l'interoperabilità tra piattaforme e sistemi su Internet. Gli standard C e C ++ forniscono intervalli per dimensioni di tipo intero, non dimensioni specifiche (in contrasto con linguaggi come Java e C #).

Per garantire che il tuo software compilato su piattaforme diverse funzioni allo stesso modo con gli stessi dati e per garantire che altri software possano interagire con il tuo software utilizzando le stesse dimensioni, devi utilizzare numeri interi di dimensioni fisse.

Immettere <cstdint>quale fornisce esattamente questo ed è un'intestazione standard che tutte le piattaforme di compilatore e di libreria standard devono fornire. Nota: questa intestazione era richiesta solo a partire da C ++ 11, ma molte implementazioni di librerie precedenti la fornivano comunque.

Desideri un numero intero senza segno a 64 bit? Usa uint64_t. Numero intero a 32 bit firmato? Usa int32_t. Mentre i tipi nell'intestazione sono opzionali, le piattaforme moderne dovrebbero supportare tutti i tipi definiti nell'intestazione.

A volte è necessaria una larghezza di bit specifica, ad esempio, in una struttura di dati utilizzata per comunicare con altri sistemi. Altre volte non lo è. Per situazioni meno rigide, <cstdint>fornisce tipi di larghezza minima.

Ci sono meno varianti: int_leastXX_tsarà un tipo intero di almeno XX bit. Utilizzerà il tipo più piccolo che fornisce XX bit, ma il tipo può essere maggiore del numero specificato di bit. In pratica, questi sono in genere gli stessi dei tipi sopra descritti che danno il numero esatto di bit.

Ci sono anche varianti veloci : int_fastXX_tè almeno XX bit, ma dovrebbe usare un tipo che funziona velocemente su una particolare piattaforma. La definizione di "veloce" in questo contesto non è specificata. Tuttavia, in pratica, ciò significa in genere che un tipo più piccolo delle dimensioni del registro di una CPU può essere alias di un tipo delle dimensioni del registro della CPU. Ad esempio, l'intestazione di Visual C ++ 2015 specifica che int_fast16_tè un numero intero a 32 bit poiché l'aritmetica a 32 bit è complessivamente più veloce sull'aritmetica x86 rispetto a 16 bit.

Ciò è importante perché dovresti essere in grado di utilizzare tipi in grado di contenere i risultati dei calcoli eseguiti dal tuo programma indipendentemente dalla piattaforma. Se un programma produce risultati corretti su una piattaforma ma risultati errati su un'altra a causa delle differenze di overflow dei numeri interi, ciò è negativo. Utilizzando i tipi interi standard, si garantisce che i risultati su piattaforme diverse saranno gli stessi per quanto riguarda la dimensione degli interi utilizzati (ovviamente potrebbero esserci altre differenze tra le piattaforme oltre alla larghezza intera).

Quindi sì, longdovrebbe essere bandito dal moderno codice C ++. Così dovrebbe int, shorte long long.

No, vietare i tipi interi incorporati sarebbe assurdo. Tuttavia, non dovrebbero essere maltrattati.

Se hai bisogno di un numero intero largo esattamente N bit, usa (o se hai bisogno di una versione). Pensare come numero intero a 32 bit e come numero intero a 64 bit è semplicemente sbagliato. Potrebbe accadere che sia così sulle tue piattaforme attuali ma questo si basa su comportamenti definiti dall'implementazione.std::intN_tstd::uintN_tunsignedintlong long

L'uso di tipi interi a larghezza fissa è utile anche per interagire con altre tecnologie. Ad esempio, se alcune parti dell'applicazione sono scritte in Java e altre in C ++, probabilmente vorrai abbinare i tipi interi in modo da ottenere risultati coerenti. (Siate ancora consapevoli che l'overflow in Java ha una semantica ben definita mentre l' signedoverflow in C ++ è un comportamento indefinito, quindi la coerenza è un obiettivo elevato.) Saranno anche preziosi per lo scambio di dati tra diversi host di elaborazione.

Se non hai bisogno esattamente di N bit, ma solo di un tipo sufficientemente largo , considera l'utilizzo di (ottimizzato per lo spazio) o (ottimizzato per la velocità). Anche in questo caso, entrambe le famiglie hanno anche controparti.std::int_leastN_tstd::int_fastN_tunsigned

Quindi, quando utilizzare i tipi predefiniti? Bene, poiché lo standard non specifica con precisione la loro larghezza, usali quando non ti interessa la larghezza effettiva della punta ma altre caratteristiche.

A charè il numero intero più piccolo indirizzabile dall'hardware. Il linguaggio in realtà ti costringe a usarlo per aliasing della memoria arbitraria. È anche l'unico tipo possibile per rappresentare stringhe di caratteri (strette).

Di intsolito è il tipo più veloce che la macchina è in grado di gestire. Sarà abbastanza largo da poter essere caricato e memorizzato con una singola istruzione (senza dover mascherare o spostare i bit) e abbastanza stretto da poter essere utilizzato con (le) istruzioni hardware più efficienti. Pertanto, intè una scelta perfetta per il passaggio di dati e l'esecuzione dell'aritmetica quando l'overflow non è un problema. Ad esempio, il tipo di enumerazione sottostante predefinito è int. Non cambiarlo in un numero intero a 32 bit solo perché puoi. Inoltre, se si dispone di un valore che può essere solo -1, 0 e 1, unintè una scelta perfetta, a meno che non ne memorizzi enormi matrici, nel qual caso potresti voler utilizzare un tipo di dati più compatto al costo di dover pagare un prezzo più elevato per accedere ai singoli elementi. Una cache più efficiente probabilmente ripagherà per questi. Molte funzioni del sistema operativo sono anche definite in termini di int. Sarebbe sciocco convertire i loro argomenti e risultati avanti e indietro. Tutto ciò che potrebbe eventualmente fare è introdurre errori di overflow.

longdi solito sarà il tipo più largo che può essere gestito con le istruzioni della singola macchina. Ciò rende particolarmente unsigned longinteressante la gestione di dati grezzi e tutti i tipi di manipolazione dei bit. Ad esempio, mi aspetto di vedere unsigned longnell'implementazione di un vettore bit. Se il codice viene scritto con cura, non importa quanto sia effettivamente largo il tipo (perché il codice si adatterà automaticamente). Su piattaforme in cui la parola-macchina nativa è a 32 bit, la matrice di supporto del vettore-bit può essere una matrice diunsignedI numeri interi a 32 bit sono più desiderabili perché sarebbe sciocco usare un tipo a 64 bit che deve essere caricato tramite istruzioni costose solo per spostare e mascherare nuovamente i bit non necessari. D'altra parte, se la dimensione della parola nativa della piattaforma è 64 bit, desidero un array di quel tipo perché significa che operazioni come "trova il primo set" possono essere fino a due volte più veloci. Quindi il "problema" del longtipo di dati che stai descrivendo, che le sue dimensioni variano da piattaforma a piattaforma, in realtà è una funzionalità che può essere sfruttata bene. Diventa un problema solo se pensi ai tipi predefiniti come tipi di una certa larghezza di bit, che semplicemente non lo sono.

char, intE longsono tipi molto utili come descritto sopra. shorte long longnon sono altrettanto utili perché la loro semantica è molto meno chiara.

Un'altra risposta elabora già i tipi di cstdint e le varianti meno conosciute al loro interno.

Vorrei aggiungere a questo:

utilizzare nomi di tipi specifici del dominio

Cioè, non dichiarare i parametri e le variabili uint32_t(certamente no long!), Ma nomi come channel_id_type, room_count_typeecc.

sulle biblioteche

Librerie di terze parti che usano longo no possono essere fastidiose, specialmente se usate come riferimenti o puntatori a quelle.

La cosa migliore è fare involucri.

Qual è la mia strategia, in generale, è quella di creare una serie di funzioni simil-cast che verranno utilizzate. Sono sovraccarichi per accettare solo quei tipi che corrispondono esattamente ai tipi corrispondenti, insieme a qualsiasi variazione del puntatore ecc. Di cui hai bisogno. Sono definiti in modo specifico per os / compilatore / impostazioni. Ciò ti consente di rimuovere gli avvisi e tuttavia garantire che vengano utilizzate solo le conversioni "giuste".

channel_id_type cid_out;
...
SomeLibFoo (same_thing_really<int*>(&cid_out));

In particolare, con tipi primitivi diversi che producono 32 bit, la scelta di come int32_tviene definita potrebbe non corrispondere alla chiamata della libreria (ad es. Int vs long su Windows).

La funzione simile a cast documenta lo scontro, prevede il controllo in fase di compilazione sul risultato corrispondente al parametro della funzione e rimuove qualsiasi avviso o errore se e solo se il tipo effettivo corrisponde alla dimensione reale coinvolta. Cioè, è sovraccarico e definito se passo (su Windows) an int*o a long*e dà un errore di compilazione in caso contrario.

Quindi, se la libreria viene aggiornata o qualcuno cambia ciò che channel_id_typeè, questo continua a essere verificato.