WndProc関数で変数を宣言/定義することは許容されます。このコードとして：
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
PAINTSTRUCT ps;
HDC hdc;
switch (message)
{
...
それが良いかどうかという質問。
プログラムは毎分何千回もこの関数に入り、これらの変数が再定義されて再び破棄されるたびに、クラス内のWndProc関数の外でこれらの変数を定義して、時間とリソースを節約する方がよいでしょうか。
プログラムは毎分何千回もこの関数に入り、これらの変数が再定義されて再び破棄されるたび
WndProcに、クラス内の関数の外でこれらの変数を定義して、時間とリソースを節約する方がよいでしょうか。
時間とリソースに関しては、ほとんど違いはありません。これらはローカル変数であり、スタックに格納されます。スレッドの作成時にスタック全体がすでに予約されており、これらの変数のメモリは、このプロシージャが最初に実行されたときまでにコミットされます。つまり、switchこれらの変数を参照しない条件の場合、変数の存在によって引き起こされる実行時またはリソースのニーズの違いを測定できない可能性があります。
レイモンドは、それWndProcを反省的に呼ぶことができると指摘します。に多くのローカル変数がある場合WndProc、結果として得られるスタックの使用量は最適ではない可能性があります。ボトルネックがスタックの使用であった実際のアプリケーションはまだ想像できませんWndProc。
そうは言っても、WndProcすべての変数を含む1つの大きなswitchステートメントであるメソッドは悪い習慣です。この関数のローカル名前空間を多くの異なる変数で汚染したくないでしょう。ウィンドウプロシージャで処理するメッセージごとに個別のハンドラ関数を作成することをお勧めします。
最後に、クラスでこれらの変数を宣言することをお勧めします。これをしないでください。可能な場合は、ローカル変数が常に優先されます。これらの変数をローカルとして宣言することは確かに可能です。それらは、呼び出す個別のハンドラー関数のローカルである必要がありWndProcますが。
ローカル変数が「作成」されると、それらすべてをスタックに収めるために部屋が割り当てられ、それらのコンストラクターが呼び出されます。コンストラクターがない場合、デフォルトのアクションはフィールドを「ゼロ」にすることだと思いますが、100％確信はありません。
ただし、これはおそらく数十の指示で達成できます。この影響は、他の操作、特にシステムコールと比較して無視できます。プログラム内のさまざまなルーチンで費やされる時間がまだ心配な場合は、gprofなどのツールを使用することをお勧めします。