私は Visual C++ Win32 プログラミングを学んでいます。、などの代わりにDWORD
、WCHAR
、などのデータ型が使用されているのはなぜですか?UINT
unsigned long
char
unsigned int
const char * の代わりにいつ WCHAR を使用するかを覚えておく必要があり、本当に面倒です。そもそも標準データ型が使用されないのはなぜですか? Win32 に相当するものを覚えておき、それらを自分の変数にも使用すると役に立ちますか?
はい、関数の引数には正しいデータ型を使用する必要があります。そうしないと、問題が発生する可能性があります。
また、これらの型が などを使用するのではなく、そのまま定義されている理由はint
、 OS のインターフェイスから「char
コンパイラint
がサイズを変更する必要があると考えるもの」を削除するためです。コンパイラ A、コンパイラ B、またはコンパイラ C を使用する場合、それらはすべて同じ型を使用するため、これは非常に良いことです。ライブラリ インターフェイス ヘッダー ファイルだけが、型を正しく定義する必要があります。
標準型ではない型を定義することint
で、たとえば 16 ビットから 32 ビットに簡単に変更できます。Windows 用の最初の C/C++ コンパイラは、16 ビット整数を使用していました。Windows が 32 ビット API を取得したのは 1990 年代半ばから後半のことで、それまでint
は 16 ビット API を使用していました。数百の変数を使用する適切に機能するプログラムがint
あり、突然、それらの変数をすべて別のものに変更する必要があると想像してみてください...特にそれらの変数の一部としては、あまり良くありません。コードの一部を 32 ビットの int に移動しても違いがないため、変更する必要はありません。そのため、これらのビットを変更しても意味がありません。
WCHAR
と同じではないことに注意してくださいconst char
-WCHAR
は「ワイド文字」であるためwchar_t
、同等のタイプです。
したがって、基本的に、「独自の型を定義する」ことは、ソース コード (の多く) を変更することなく、基礎となるコンパイラ アーキテクチャを変更できることを保証する方法です。マシン依存のコーディングを行う大規模なプロジェクトはすべて、この種のことを行います。
int
およびなどの組み込み型のサイズとその他の特性はlong
、通常、コードが実行されているシステムの基礎となるアーキテクチャに応じて、コンパイラごとに異なる場合があります。
たとえば、Windows が最初に実装された 16 ビット システムでは、int
はちょうど 16 ビットでした。最新のシステムでint
は、32 ビットです。
Microsoft は、DWORD
さまざまなバージョンのコンパイラ、または Windows コードのコンパイルに使用される他のコンパイラでサイズが同じになるように、のような型を定義します。
また、名前は、Microsoft によって定義されているように、基になるシステムの概念を反映することを目的としています。ADWORD
は「ダブル ワード」です (正しく思い出せば、Windows では 32 ビットですが、最新のシステムではマシンの「ワード」はおそらく 32 ビットまたは 64 ビットです)。
や<stdint.h>
などの で定義されている固定幅型を使用する方がよかったかもしれませんが、これらは 1999 年の ISO C 標準 (Microsoft のコンパイラは今日でも完全にはサポートしていません) によって C 言語に導入されただけです。uint16_t
uint32_t
Win32 API と対話するコードを作成している場合は、その API で定義された型を必ず使用する必要があります。Win32 と対話しないコードの場合は、好きな型を使用するか、使用しているインターフェイスで提案されている型を使用します。
歴史的な事故だと思います。
私の理論では、元の Windows 開発者は、標準の C 型のサイズがコンパイラに依存することを知っていました。つまり、あるコンパイラには 16 ビット整数があり、別のコンパイラには 32 ビット整数がある可能性があります。そのため、一連の typedef を使用して異なるコンパイラ間で Window API を移植できるようにすることにしましたDWORD
。使用しているコンパイラ/アーキテクチャに関係なく、32 ビットの符号なし整数です。当然、今ではuint32_t
fromを使用します<stdint.h>
が、これは当時は利用できませんでした。
それから、UNICODE の件で、彼らはTCHAR
vs. CHAR
vs.WCHAR
の問題を抱えていましたが、それはまた別の話です。
そして、それは制御不能になり、typedef void VOID, *PVOID;
まったくナンセンスなほど素晴らしいものが得られます.