・ＡＰＩやＭＦＣでLPCTSTRを引数に求めているのならLPCTSTR型の変数を渡すのが道理、と素直に感じます。この型に対してTCHAR型の配列を渡すのは少し違和感を覚えるのですが。 　普通の変数とポインタ変数を、まったくの別物と考えるのが違和感を消す近道だと思います。「ポインタを単独で作ることはない」とまず考えて、「LPCTSTR型の変数も作るはずがない」と考えていくべきでしょう。 　また、同時に参照を使い、「参照の引数に渡すのもポインタの引数に渡すのも意味は同じ」ととらえれば、引数にポインタを使う理由を理解しやすくなると思います。 　最後に、自分で作る関数にポインタを使って、ポインタをなぜ引数に使うのか、ということを考えれば、違和感はなくなっていることでしょう。

・LPRECT型のようなものが引数に出てきた場合、RECTなら＆を付けて渡せばいいのは分かるのですが、CRectを使う場合にはどう渡せばいいのかいまいちよく分かりません。どう判断するのがいいのでしょうか。 　こういう場合、まずクラスのメンバ関数を調べてみてください。クラスは「型変換演算子関数」というメンバ関数を備えることができます。これは「特定の型を要求された時に呼び出す関数」です。 　CRectには、LPRECTへと代入されようとしたときに呼び出されるCRect::operator LPRECT()という関数が備わっています。この関数は適切なRECTのポインタを返してくれます。この関数のおかげで、LPRECTを要求されている時にはそのままCRectを渡せることになっています。同様の関数はCStringにも備わっています。 　ところが、この関数が備わっていないクラスもあります。CPointやCSizeがそうです。これらの場合には「継承元」をチェックしてください。これらのクラスは、それぞれPOINTやSIZEと同じ構造体から継承されています。そこで、構造体と同じように＆を付けて渡せばＯＫです。 　この手順で試してみて、コンパイルエラーが起きるのなら渡さない方が無難でしょう。

・LPRECT型のように、ポインタをなぜわざわざ別の型として定義するのでしょうか。紛らわしいだけだと思います。 　これにはふたつの理由があります。 　ひとつは＊の付け忘れを防ぐためです。

・ＡＰＩのSHBrowseForFolder()で使うBROWSEINFOの各メンバで、値を渡すのか受け取るのかよく分かりません。なぜこのように分かりづらいのでしょうか。また、どのように区別すればいいのでしょうか。 　これは僕も分かりにくいと思います。構造体丸ごとポインタとして渡すため、どのメンバからデータを取得してどのメンバに値が返されるのか分かりにくくなっています。目安としては、specifiesがあったら渡すメンバ、receivesがあったら受け取るメンバだととらえてほぼ間違いないでしょう。 　自分で関数を組む場合には、できるだけこのような仕様は避けるべきでしょう。たとえば構造体を使わずすべて関数の引数に渡す形にするとか、構造体をふたつに分け、渡す側はconstにしてしまう、といった方法を採るのがバグを減らすコツといえるでしょう。

・free()やdeleteはなぜメモリの領域を開放できるのでしょうか。sizeof()では確保された領域のサイズが分からないのですから、どれだけの領域を開放すればいいのか分からないはずだと思います。また、何らかの方法でサイズを取得できるのだとしたら、そういう関数はなぜ存在しないのでしょう。あれば、文字配列を渡す時にサイズも渡さずに済むと思うのですが。 　基本的にこの関係の実装は関数やコンパイラ、ＯＳなどによって変わってくるので一概には言えません。ただ、malloc()とfree()のペアは、確保したメモリブロックとそのポインタをリストとして保存し、解放時にポインタを元にリストから検索して解放すべきサイズを取得しています。また、Ｍｉｃｒｏｓｏｆｔの独自拡張としてこのサイズを取得する関数も存在します。 　重要なのはそれぞれまったく違う方法でメモリブロックの情報を保存しているかもしれないということです。確保するものでもnewやmalloc()の他に、HeapAlloc()やGlobalAlloc()、CoTaskMemAlloc()といったＡＰＩも存在し、それぞれが別々の実装方法を持っています。 　問題なのは、このどれを使用しても、結局はポインタが返ってくるということです。つまり一見しただけではどの関数を用いて確保されたのか分かりません（もちろんスタック領域に作成されたものかもしれないのです）。そのため、現実的には「ポインタが指す領域がどうやって作成されたのか」に依存するようなコードは書けないということになります。 　これは結構大きな問題です。確保する部分と開放する部分が離れている場合、確保は複数種の関数を使用し、解放にdeleteのみ使う、といったことをしてしまう可能性が出てきます。確保と解放、このふたつはペアとして正確に使用することにしましょう。 　ちなみに最善手は、ポインタを格納するクラスを作って、確保と解放をメンバ変数にすることです。そうすれば絶対に失敗しません。実装はちょっとややこしくなりますが……。

・void *やLPVOIDはどのようなポインタなのでしょうか。普通voidは「戻り値のない関数」に使用するので、型になるというイメージが沸きません。 　voidとvoid *は別物と考えるべきでしょう。voidポインタは、「特に型の指定されていないポインタ」という意味です。次のコードを試してみてください。

・ポインタをLPARAMやWPARAMに型変換して関数に渡したり、逆にこれらを構造体のポインタへと型変換するコードをよく見かけます。なぜこのようなことをしているのでしょうか。プログラムとしてこれは正しいのでしょうか。 　ウィンドウズ９５ではポインタは３２ビット整数値として扱われます。WPARAMはunsigned int、LPARAMはintと同じなのでこれらも同様に３２ビット整数です。そのため、型変換すればそのまま渡せます。 　これはｖｏｉｄポインタ以上にフレキシブルな操作ができることを意味しています。形にとらわれずありとあらゆるものを渡せることになるため、これもバグの可能性を生みます。 　ただ、ウィンドウズのメッセージシステムはこの方法をフル活用しているため、使用せざるを得ないのが実状です。ＭＦＣのメッセージハンドラはこの変換をメンバ関数内にパッケージングしているので、同様にうまく外部から干渉されないようにし、できるだけ使わないようにするのがいいでしょう。

・次のコードは関数の戻り値としてポインタを使っていますが、かといってポインタが指し示す文字列はスタック上に作成されているので、関数が終了したら削除されると思います。このコードはあっているのでしょうか。

・同じく、CDC::GetWindow()もCWnd *を返します。deleteしなくていいのでしょうか。どこかでされるのだとしたら、どのようなタイミングで行われるのでしょうか。 　deleteする必要はありません。これらのポインタを返すメンバ変数を使用した場合、このポインタはマップに格納されます。マップに格納されたポインタは、メッセージキューが空になった状態、いわゆる「アイドル状態」になったときに自動的に削除されます。このシステムにより、基本的にCDC::GetWindow()を呼び出した関数内ではポインタは正当性が失われませんが、関数から抜けた後はいつ削除されても不思議ではない、ということになります。 　このような、プロセス内でグローバルな変数が多く存在する実装方法はある意味「ＭＦＣらしい」と言えますが、この方法によりマルチスレッドプログラミングが難しくなっています。自分で実装する場合には真似しない方がいいでしょう。

・さらに同じく、CDC::GetWindow()はなぜわざわざポインタを返すのでしょうか。CWndそのものや、HWNDを返しても構わないと思いますが、何か意図があるのでしょうか。 　これにはオブジェクト指向的な理由があります。まず、ＭＦＣの「ハンドルをメンバ変数に持つクラス」は、「ハンドルのラッパークラス」としてではなく「ウィンドウズオブジェクトそのもの」として捉えられています。 　たとえばCWnd型はデストラクタが自動的にウィンドウを破棄します。「変数がなくなったとき、オブジェクトもなくなる」という考え方です。そのため、すでに存在するウィンドウのハンドルをCWnd::Attach()で渡したあと、CWnd::Detach()を呼び出さないと、スコープから出た変数がウィンドウを削除してしまいます。 　CDC::GetWindow()は、こういった考え方に合わせてCWndのポインタを返します。もしCWndそのものを返したら、それは「すでにあるウィンドウの複製を作成してしまう」ということになります。 　すでにウィンドウが存在し、それを操作する、そのための「コントローラー」としてポインタを渡します。ポインタは破棄されてもデストラクタは呼ばれないため、ウィンドウが勝手に削除されることはありません。 　もともと、この考え方はHWNDのようなハンドル的なものです。ハンドルは一種のポインタで、ウィンドウズオブジェクトを操作するための「コントローラー」の役目を持っています。ＭＦＣでのハンドルの代わりが、オブジェクトクラスへのポインタということになるでしょう。

・ＣＯＭインターフェイスのIShellFolder::EnumObjects()は第３引数にLPENUMIDLIST *、つまり「ポインタのポインタ」を渡すよう指示しています。なぜこのようなことをしているのでしょうか。また、「ポインタのポインタのポインタ」や「ポインタのポインタのポインタのポインタ」は存在するのでしょうか。 　これは前述の「オブジェクト指向的な考え方」の影響です。ＣＯＭインターフェイスは「どこかに実体があり、それをポインタを使って操作する」という考え方を持っています。そのため、ＣＯＭインターフェイスを操作するためには、オブジェクトそのものではなく、オブジェクトのポインタが必要になります。 　そのポインタを取得するための方法が「ポインタのポインタ」です。「ポインタを受け取る変数のアドレスを渡す」と考えると分かりやすいでしょう。また、ポインタをハンドルに置き換えて「ハンドルを受け取る変数のアドレスを渡す」と考えてもいいでしょう。 　この方法としては、「受け取る変数へのポインタ」を渡せばいいので、「ポインタのポインタのポインタ」などは使いません。ただし、これらは多次元配列を作成するときにしばしば使用します。具体的な使い方はアルゴリズムの本などをご覧ください。

・次のようなコードを見かけました。スタック領域に作成できるのに、なぜわざわざ動的に確保しているのか理解できません。メモリリークを発生させてバグが生まれる可能性が高まるだけだと思うのですが。