VS2019编译报错E0167？手把手教你解决const wchar_t与WCHAR类型冲突问题

原创

于 2026-02-27 05:33:30 发布 · 281 阅读

VS2019编译报错E0167：深入解析字符串类型冲突与现代化C++的解决之道

最近在将老项目迁移到Visual Studio 2019时，不少开发者都遇到了一个看似熟悉却又令人头疼的编译错误——E0167。这个错误信息通常指向const wchar_t*与WCHAR*（或LPCSTR等）之间的类型不兼容问题。表面上看，这只是个简单的类型转换警告，但背后却牵扯到C++语言标准的演进、微软编译器对标准符合性的提升，以及我们编写跨版本兼容代码时需要具备的现代思维。如果你正在为这个错误焦头烂额，或者想从根本上理解为何过去能跑的代码现在突然“罢工”，这篇文章将带你从现象深入到本质，并提供不止一种清晰、可落地的解决方案。

1. 错误重现与根源剖析：不只是“const”的问题

首先，让我们亲手触发一下这个错误，理解它的具体形态。假设你有一段遗留的DirectX或Win32 API封装代码，其函数签名使用了传统的WCHAR*来接收宽字符串文件名。

// 一个典型的、可能引发错误的函数声明（.h文件）
class ShaderUtility {
public:
    void LogShaderError(ID3DBlob* errorBlob, HWND window, WCHAR* filename); // 注意这里的参数类型
};

// 对应的函数调用（.cpp文件）
void SomeFunction() {
    ShaderUtility util;
    // 使用字符串字面量调用函数
    util.LogShaderError(pErrorBlob, hWnd, L"shader.fx"); // 这里会触发E0167错误
}

当你尝试在VS2019中编译上述代码时，编译器会毫不留情地报错： E0167: “const wchar_t *” 类型的实参与 “WCHAR *” 类型的形参不兼容

为什么过去可以，现在不行？

这绝非VS2019在“找茬”，而是微软编译器在持续提升对C++语言标准（特别是C++11及之后）的符合性。核心原因在于字符串字面量（string literal）的类型。

在C++中，一个像L"shader.fx"这样的宽字符串字面量，其类型是const wchar_t[N]（N为字符串长度加1）。当它退化为指针时，得到的是const wchar_t*，这是一个指向常量数据的指针。将这个指针传递给一个期望接收WCHAR*（即wchar_t*，非const指针）的函数，意味着你试图将一个“只读”数据的地址，交给一个可能修改其内容的函数参数。这在现代C++标准下被视为不安全的隐式转换，因此被编译器严格禁止。