C++ 处理具有不同字符集的库的头文件中的TCHAR

我有一个使用两个第三方库的项目，这两个库都在头文件中使用了TCHARs。不幸的是，一个库被编译为多字节（称为库a），另一个库被编译为Unicode（称为库b）

现在我的理解是，TCHAR被预编译器替换为wchar或char，具体取决于构建选项。因此，在编译库a时，采用TCHAR类型参数的任何方法都被设置为预期char类型参数，而库b中的方法被设置为预期wchar类型参数

不幸的是，我的消费应用程序也必须选择一个字符集。如果我选择Unicode，那么我为库a包含的头文件告诉我该方法需要一个wchar，因为当我编译头中的TCHAR时，它们被解释为wchar。这包括结构内部定义的TCHAR。我已经在实践中证实了这种行为，当我分配并传递一个TCHAR缓冲区时，我得到了垃圾，因为它用多字节数据填充了我的wchar缓冲区

---

我的问题是：有没有一种干净的方法可以在同一个应用程序中使用这两个库？我使用这些库的方式是否有问题？

我认为最好的选择是选择库a或库b（本例中我们称为库a）的方式。然后，当您包含库b头文件时，请确保您#定义/#取消定义编译库b时使用的任何库。然后，您必须确保只要库a和库b使用相同的数据，就可以在它们之间进行转换

---

如果您能以同样的方式编译它们，那将是最好的。否则会非常混乱

假设在这两个库中都没有使用过多的类/函数，我将完全包装其中一个库。假设您决定在应用程序中使用mbc并包装库b（unicode），那么您的包装头文件可以使用

wchar\u t

而不是

TCHAR

，因此#define不会影响您的界面。在包含库b的头的包装器cpp文件中，定义

TCHAR

以匹配库b。除了包装器之外，不允许任何代码看到库b

如果在这两个库中都使用了多个类/函数，那么维护包装器代码很快就会成为一个问题。

正如建议的那样，最好在自己的API中包装差异。这使您的源代码独立于它

---

然后包装API必须将编码中的字符转换为库中的字符。在windows上，我可以为您调用函数等。

谢谢您的回答，这就是我所倾向的方向。我要冒险去问一个愚蠢的问题。与只编辑库的头文件以使其匹配结构和导出函数的编译定义相比，使用包装器有什么好处？我想象这就像搜索和替换TCHARs一样简单。我是不是过于简化了？xtofl指出了下面的一个优点：您可以在包装器中进行多字节之间的转换。我想我最感兴趣的是关于find/replace是否有效的反馈。在库头文件中用char/wchar\t替换TCHARs只会在替换所有它们（包括库头文件中通过#include包含的头文件）时起作用。取决于您的库，其中可能包括一些标准/系统文件。另一个缺点是，当您获得库的新版本时，您会做什么？再次搜索并替换？