您将一种编码的文本文字与另一种编码的函数调用混合在一起。
所有这些混乱都是由于微软放在他的标题上的#defines 和typedefs 的模糊链。
其中一个烦人的 Microsoft 技巧是声明两个函数调用,根据项目设置,用字母 A 或 W 区分。如果定义了UNICODE,则有一个宏可以将GetFileAttributes 转换为GetFileAttributesA 或GetFileAttributesW。
在您的情况下,您将摆脱宏并直接调用UNICODE 版本(以字母W 结尾的版本)但在您的调用中您使用的是非宽字符串文字,您可以修复它很容易将L 附加到文字(如其他用户所建议的那样):
if(GetFileAttributesW(L"C:\\Directory")!="INVALID_FILE_ATTRIBUTES") {...}
因此,如果您调用以A 结尾的版本,则可以使用无宽字符串文字:
if(GetFileAttributesA("C:\\Directory")!="INVALID_FILE_ATTRIBUTES") {...}
修复它的其他方法是使用_T 宏(检查this answer):
if(GetFileAttributesW(_T("C:\\Directory"))!="INVALID_FILE_ATTRIBUTES") {...}
但是如果UNICODE没有定义,你原来的问题会再次出现;最后,你可以屈服于微软的做事方式,使用提供的所有宏:
// Note the lack of W or A, it's a macro, not a function call!!
if(GetFileAttributes(_T("C:\\Directory"))!="INVALID_FILE_ATTRIBUTES") {...}
使用两个宏(一个将GetFileAttributes 更改为UNICODE 或no-UNICODE 版本,另一个将L 附加到文字),无需担心项目设置因为宏为你承担了这个责任。
编辑。
糟糕,我差点忘了最重要的部分。
正如其他用户所指出的,您将GetFileAttributes 的返回值与文本文字进行比较;它返回一个 DWORD 并根据 Microsoft 文档:
DWORD 是一个 32 位无符号整数(范围:0 到 4294967295 十进制)。
所以,最后,您将整数与char[24] 进行比较,比较是可能的,但永远不会是真的!您必须阅读有关该功能以及如何使用它的信息;)