Windows編程和數據類型

我目前正在開發一個Windows應用程序項目。我正在用Windows API開發它，我需要設置一些標準。Windows編程和數據類型

重要的一個：

我應該使用Windows數據類型（DWORD，TCHAR，LPSTR ...）或標準數據類型？
我應該在我的代碼中的任何地方使用它們還是僅使用它的某些部分？

謝謝。編輯：你怎麼看待SAL註釋？ http://msdn.microsoft.com/en-us/library/hh916382.aspx

我應該在頭文件中使用它嗎？

來源

2013-07-21 LppEdd

DWORD總是4個字節，但對於不同的編譯器和平臺，「long」可以是4個字節或8個字節。 DWORD在IntSafe.h中聲明，因此必須比其他安全:) –

部分是見仁見智，但我的建議是：

我會說是喜歡的東西DWORD。您不應該爲Windows數據類型假設特定的基礎類型。你只應該假設如果函數說明需要DWORD，那麼你需要提供一個DWORD。它確保瞭如果微軟更改了底層類型，那麼你的代碼仍然可以在沒有最小變化的情況下工作。

這方面的一個很好的例子是WPARAM和LPARAM類型，我覺得已經改變了幾次。現在，它們基本上被定義爲「足夠大以容納指針」，這意味着它們在32位和64位Windows之間的大小不同。

我會拒絕像LPCTSTR這樣的東西，因爲對我來說更清晰的說const TCHAR* - 整個「長指針」的東西是16位Windows的遺蹟。但是請注意，我說的是const TCHAR*而不是const wchar_t*。

當談到在任何地方使用它時，我都會說絕對不要將它用於需要可移植的代碼的任何部分 - 儘管您可以創建自己的typedef，其基礎類型是Windows數據類型編譯爲Windows，如：

typedef TickCount DWORD;

我將主要與麻煩，如果你要使用可能有一個「滴答計數」的概念，需要在其他操作系統上運行的代碼，但在那無論如何，你需要在你的代碼和Windows API之間建立一個抽象層。

更新編輯的問題：

我沒有與SAL我自己的經驗，但它似乎並不像第一眼一個可怕的想法。它明確瞭如何在不依賴文檔的情況下使用參數，以及MSDN文檔說他們將它與靜態代碼分析工具結合使用。如果您有這樣的工具可以確認您正確使用註釋，那麼對我來說這似乎是一件好事。我的直接反應是它確實使聲明更難以閱讀，但關於定義API的最棘手問題之一就是確保預期的行爲得到充分記錄和理解。

來源

2013-07-21 15:07:24 Joel

非常好的答案！ – LppEdd

對於直接轉到Windows API的值，請使用Windows類型。對於只用於自己內部計算的值，請使用自己的類型（或類似stdint.h）。對於兩者都使用的值，請使用您自己的類型，並在需要時轉換爲Windows類型。這個問題的

來源

2013-07-21 15:02:56 tohava

Windows編程和數據類型

回答

相關問題