2013-10-28 28 views
2

在Visual C我:顯式轉換總是與隱式轉換相同嗎?

#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1) 
typedef int HFILE; 
HFILE stat_fh = INVALID_HANDLE_VALUE; 

和我有警告:

"..warning C4047: '=' : 'HFILE' differs in levels of indirection from 'HANDLE'" 

那是正確的,如果我通過鑄造INVALID_HANDLE_VALUEHFILE類型刪除警告? 我假設編譯器已經自動完成了完全相同的事情。

+1

除非我想念你要完成什麼,你應該使用'HFILE_ERROR'爲貴「無效」'HFILE'手柄。 – WhozCraig

+0

你也應該閱讀[這裏](http://stackoverflow.com/questions/320893) –

+1

@ mas.morozov:我已經編輯您的編輯。不存在「隱式演員」這樣的事情。看到我的答案的第二段。 –

回答

1

是的,當這兩種類型的轉換(「石膏」)是適用 - 顯性和隱性 - 顯性轉換的語義是完全一樣的隱式轉換的語義。

但請注意,在你的情況下,沒有明顯的隱式轉換是適用的。在WinodwsAPI中HANDLE通常被定義爲一個指針類型。您正試圖將其轉換爲int類型。標準C不允許從指針類型到int的隱式轉換。這意味着以下聲明

HFILE stat_fh = INVALID_HANDLE_VALUE; 

包含約束違規。即它應該是不可編譯的。所以,你的問題實際上是沒有意義的(假設將HANDLE轉換爲int真的是你想要做的)。明確演員陣容是只有選項在這種情況下。

如果你的編譯器可以隱式做這種轉換(用僅有的警告),那麼它只是一個編譯器的怪癖,不相關的標準C語言都沒有。

+0

它與C語言有關。該標準要求*診斷*用於任何違反約束或語法錯誤;它不要求診斷是一個致命的錯誤。非致命的警告符合標準的要求。 (其中標準要求翻譯單元被*拒絕的唯一情況*是當有一個'#error'指令。) –

+0

*這兩種類型的轉換(「石膏」)是適用 - 顯性和隱性*只有明確的一個是演員。演員總是明確的。 – glglgl

1

它可能正常工作,但並不好(儘管它似乎是微軟期望的;請參閱下文)。

首先,您的術語有點偏離。 A 轉換是一個運算符,由括號中的類型名組成。它指定了一個明確的轉換。不存在隱式轉換或「自動轉換」的情況。你所說的「強制演員」只是一個演員;你所說的「自動轉換」是一個隱式轉換

HFILE只是int的另一個名字。根據Microsoft's documentationHANDLEvoid*的typedef(別名)。該語言沒有定義從任何指針類型到int的隱式轉換。在這種情況下,您的編譯器會讓您擺脫困境併發出警告。實際上,分配是約束衝突,需要診斷消息。您的編譯器可能(和恕我直言應該)只是拒絕您的程序與致命的錯誤信息。

如果您有一個指針值,則應將其分配給相同類型的指針變量

如果你想分配HANDLE價值stat_fh,那麼你應該聲明stat_fhHANDLE,而不是作爲int(甚至爲HFILE,這正如我所說的僅僅是int的另一個名字)。

爲什麼你定義 HFILE作爲 int的別名?

UPDATE:

我看到HFILE微軟實際上是定義爲:

typedef int HFILE; 

他們的文檔也說HFILE是「A手柄由OpenFile打開的文件,不是CreateFile「。如果你關注這些鏈接,你會發現不建議使用OpenFile

在另一方面,對於OpenFile的文件說,文件由OpenFile打開(它返回一個HFILE,即,int)應通過將手柄CloseHandle,這需要關閉的HANDLE(即void*)論據。

這真是令人震驚,我想這是微軟決定阻止使用OpenFile的原因之一。

據我所知(雖然我不是Windows程序員,所以我可能會錯過某些東西),但沒有理由使用HFILE

+1

是的,我在理論上同意Keith的觀點,但實際上,核心Win32 API就是這樣一個簡單的東西,你只是習慣了這些問題。 – StilesCrisis

+0

@ mas.morozov:我沒有意識到HFILE是微軟的定義。我很震驚。但MS的文檔(請參閱上面的鏈接)說'HFILE'由'OpenFile'返回,這是不推薦的; 'CreateFile',推薦的功能,返回一個'HANDLE'。 –

+0

@StilesCrisis:查看我的更新。 –

相關問題