如果檢視返回handle的各種函式, 你就會發現其中一些返回null(例如createthread)，而另一些會返回invalid_handle_value(例如createfile)。所以，你必須檢視相關的msdn文件，才能確定函式在執行失敗時的返回值的意義。
可能你早就猜到了：因為歷史原因。
這些控制代碼的值被這樣選擇，主要是為了和16位windows保持相容。
16位函式openfile，_lopen和_lcreat在失敗時返回-1，因此32位createfile函式返回invalid_handle_value以便於從win16移植**。
(知道了這個，我們就應該可以回答這個問題您現在可以回答以下瑣事問題：為什麼我想開啟乙個檔案時需要呼叫createfile? 不是應該呼叫openfile嗎？答：當然可以，openfile是乙個更好的名稱，但是該名稱已被使用。)
另一方面，對於createthread或createmutex，沒有win16對應的版本，因此它們返回null。
由於現在已經為不一致的返回值設定了先例，因此無論何時新增新函式，新函式是否返回null或invalid_handle_value都有些麻煩。
首先，當然，你必須小心檢查正確的返回值。
其次，這意味著，如果編寫通用的控制代碼包裝類，則必須注意兩個可能的」非控制代碼」值。
第三，如果要預初始化控制代碼變數，則必須以與要使用的功能相容的方式對其進行初始化。例如，以下**是錯誤的：
以上**有兩個錯誤。
首先，從createfile返回的值檢查不正確。 上面的**檢查null而不是invalid_handle_value。 其次，**錯誤地初始化了h變數。下面是更正後的版本：
第四，你必須特別小心invalid_handle_value值：巧合的是，值invalid_handle_value恰好在數值上等於getcurrentprocess()返回的偽控制代碼。許多核心函式都接受偽控制代碼，因此，如果你搞砸了並且不小心在乙個失敗的invalid_handle_value控制代碼上呼叫了waitforsingleobject，實際上你將最終等待自己的程序。
當然，這種等待永遠不會完成，因為當退出某個程序時會發出訊號，因此你最終要等待你自己。
如有必要，請檢查每乙個win32 api的返回值。
為什麼建構函式沒有返回值？
意見 1 我認為建構函式隱含的返回值就是this,因為建構函式是在類的物件產生時自動呼叫。建構函式被呼叫也就意味著產生了乙個物件，而this指標是與物件實體相關聯的，所以我認為它返回的就是this。舉例如下 class a a aa 此語句導致類a的建構函式a 被自動呼叫返回乙個首位址，系統就在記憶...
函式失敗返回 C 的返回值return
return表示從被調函式返回到主調函式繼續執行，返回時可附帶乙個返回值，由return後面的引數指定。函式可以有返回值也可以沒有返回值，當沒有返回值時，函式型別宣告為void型。每個函式都有型別，如果在定義中沒有給出型別則預設為int型。main 也是函式，並且其返回值總是乙個整數。return通...
為什麼 HANDLE 返回值不同
如果你注意各種返回 handle 值的函式,你會發現它們有些返回 null 如 createthread 而有些則返回 invalid handle value 如 createfile 你不得不查詢文件找出每種函式在失敗時返回什麼。為什麼返回值不統一？如你所猜測，是歷史原因。這些值是用於相容16位...