Perché i tipi di dati standard non sono utilizzati nell'API Win32?

Question

Sto imparando la programmazione Win32 di Visual C++ da un po 'di tempo. Perché ci sono i tipi di dati come , WCHAR, UINT ecc. Usati invece di, ad esempio, unsigned long, char, unsigned int e così via?

Devo ricordare quando utilizzare WCHAR invece di const char *, e mi disturba davvero. Perché non sono i tipi di dati standard utilizzati in primo luogo? Aiuterà se memorizzo gli equivalenti di Win32 e li uso anche per le mie variabili?

Answer 1

Sì, è necessario utilizzare il tipo di dati corretto per gli argomenti per le funzioni oppure è probabile che si trovi in ​​difficoltà.

E la ragione che questi tipi sono definiti come sono, invece di usare int, char e così via è che si rimuove il "qualunque sia il compilatore pensa un int devono essere dimensionati come" dall'interfaccia del sistema operativo. Il che è una cosa molto buona, perché se si utilizza il compilatore A, o il compilatore B, o il compilatore C, tutti useranno gli stessi tipi: solo il file di intestazione dell'interfaccia della libreria deve fare la cosa giusta per definire i tipi.

Definendo tipi che non sono tipi standard, è facile cambiare int da 16 a 32 bit, ad esempio. I primi compilatori C/C++ per Windows utilizzavano numeri interi a 16 bit. Solo a metà degli ultimi anni '90 Windows ha ottenuto un'API a 32 bit e fino a quel momento stavi usando int a 16 bit. Immagina di avere un programma ben funzionante che utilizza diverse centinaia di variabili int e, all'improvviso, devi modificare TUTTE queste variabili in qualcos'altro ... Non sarebbe molto bello, giusto - specialmente come ALCUNI di quelli le variabili NON hanno bisogno di essere cambiate, perché passare a un int a 32 bit per alcuni dei tuoi codici non farà alcuna differenza, quindi nessun punto nel cambiare quei bit.

Va notato che WCHAR non è lo stesso di const char - WCHAR è un "wide char" in modo wchar_t è il tipo comparabile.

Quindi, in sostanza, il "definire il nostro tipo" è un modo per garantire che sia possibile modificare l'architettura del compilatore sottostante, senza dover modificare (molto del) codice sorgente. Tutti i progetti più grandi che fanno la codifica dipendente dalla macchina fanno questo genere di cose.

Answer 2

Le dimensioni e altre caratteristiche dei tipi built-in come int e long possono variare da un compilatore all'altro, in genere in base all'architettura di base del sistema su cui è in esecuzione il codice.

Ad esempio, sui sistemi a 16 bit su cui è stato originariamente implementato Windows, int era solo 16 bit. Sui sistemi più moderni, int è a 32 bit.

Microsoft può definire tipi come DWORD in modo che le loro dimensioni rimangano le stesse su versioni diverse del compilatore o su altri compilatori utilizzati per compilare il codice di Windows.

E i nomi hanno lo scopo di riflettere concetti sul sistema sottostante, come definito da Microsoft. A DWORD è una "doppia parola" (che, se ricordo correttamente, è di 32 bit su Windows, anche se una "parola" di macchina è probabilmente 32 o anche 64 bit sui sistemi moderni).

Forse sarebbe stato meglio utilizzare i tipi a larghezza fissa definiti <stdint.h>, come uint16_t e uint32_t - ma quelli sono stati introdotti solo per il linguaggio C dal 1999 ISO C standard (che il compilatore di Microsoft non è pienamente supporto anche oggi).

Se si sta scrivendo il codice che interagisce con l'API Win32, è consigliabile utilizzare i tipi definiti da tale API. Per il codice che non interagisce con Win32, usa i tipi che ti piacciono, o quelli che sono suggeriti dall'interfaccia che stai usando.

Answer 3

Penso che sia un incidente storico.

La mia teoria è che gli sviluppatori di Windows originali sapevano che le dimensioni del tipo C standard dipendono dal compilatore, ovvero un compilatore può avere un numero intero a 16 bit e un altro un numero intero a 32 bit. Così hanno deciso di rendere portatile l'API di Windows tra diversi compilatori utilizzando una serie di typedef: DWORD è un intero senza segno a 32 bit, indipendentemente dal compilatore/architettura che si sta utilizzando. Naturalmente, al giorno d'oggi si utilizzerà uint32_t da <stdint.h>, ma questo non era disponibile in quel momento.

Quindi, con la cosa UNICODE, hanno ottenuto il vs. CHAR rispetto al numero WCHAR, ma questa è un'altra storia.

E, poi, è diventato fuori controllo e si ottiene cose così belle come typedef void VOID, *PVOID; che sono assolutamente prive di senso.