雖然它對我沒有問題，但我擔心它會在未來的某一天在我臉上爆炸，
LPRECT pRect = reinterpret_cast<LPRECT>(lParam);
我需要知道在攔截時reinterpret_castLPNCCALCSIZE_PARAMS是否安全，如果我需要只處理或不管其余的將是！LPRECTWM_NCCALCSIZE(LPNCCALCSIZE_PARAMS)lParam->rgrc[0](LPARAM)lParamNCCALCSIZE_PARAMS
參考：
https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-nccalcsize https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-nccalcsize_params
uj5u.com熱心網友回復：
物件的記憶體地址與其第一個資料成員的記憶體地址相同。并且陣列的記憶體地址與其第一個元素的記憶體地址相同。
根據WM_NCCALCSIZE檔案：
引數
如果 wParam 為 TRUE，lParam 指向一個 NCCALCSIZE_PARAMS 結構，該結構包含應用程式可以用來計算客戶矩形的新大小和位置的資訊。
如果 wParam 為 FALSE，則 lParam 指向一個 RECT 結構。輸入時，該結構包含建議的視窗矩形視窗。退出時，該結構應包含相應視窗客戶區的螢屏坐標。
由于 的第一個資料成員NCCALCSIZE_PARAMS是一個RECT[3]陣列：
typedef struct tagNCCALCSIZE_PARAMS {
RECT rgrc[3];
PWINDOWPOS lppos;
} NCCALCSIZE_PARAMS, *LPNCCALCSIZE_PARAMS;
那么邏輯上，總會有一個RECT位于 指向的記憶體地址lParam，是的。
但從技術上講，在 C 下，您提出的是嚴格別名違規 when wParamis TRUE，因為lParam將指向 a NCCALCSIZE_PARAMS，而不是 a RECT。每個cppreference.com：
嚴格的別名
給定一個具有有效型別 T1 的物件，使用不同型別 T2 的左值運算式（通常是取消參考指標）是未定義的行為，除非：
- T2 和 T1 是兼容型別。
- T2 是與 T1 兼容的型別的 cvr 限定版本。
- T2 是與 T1 兼容的型別的有符號或無符號版本。
- T2 是一種聚合型別或聯合型別，在其成員中包括上述型別之一（遞回地包括子聚合或包含聯合的成員）。
- T2 是字符型別（char、signed char 或 unsigned char）。
NCCALCSIZE_PARAMS您將 a當作 a訪問的建議RECT不滿足這些要求。
但是，由于 Win32 API 主要是為 C 而不是 C 設計的，您的建議可能會在大多數 C 編譯器中“作業”。
But, to be on the safe side, you really should cast lParam to the correct type based on the value of wParam, eg:
LPRECT pRect;
if (wParam) {
pRect = &(reinterpret_cast<NCCALCSIZE_PARAMS*>(lParam)->rgrc[0]);
// or:
// pRect = reinterpret_cast<NCCALCSIZE_PARAMS*>(lParam)->rgrc;
}
else {
pRect = reinterpret_cast<LPRECT>(lParam);
}
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/438366.html
上一篇：MFC:CDHtmlDialog目的/用法打開其他視圖？
下一篇：捕獲子行程的OpenGL輸出？