处理具有不同字符集的库的头文件中的 TCHAR
我有一个使用两个第三方库的项目，这两个库都在其头文件中使用了 TCHAR。 不幸的是，一个库被编译为多字节（称为库 a），而另一个库被编译为 Unicode（称为库 b）。
现在我的理解是 TCHAR 被预编译器替换为 wchar 或 char，具体取决于构建选项。 因此，当编译库 a 时，任何采用 TCHAR 类型参数的方法都被设置为期望 char 类型的参数，而库 b 中的方法被设置为期望 wchar 类型的参数。
不幸的是，我的消费应用程序也必须选择一个字符集。 如果我选择 Unicode，那么我为库 a 包含的头文件告诉我该方法需要 wchar，因为当我编译头中的 TCHAR 时，它们会被解释为 wchar。 这包括结构内部定义的 TCHARS。 我在实践中证实了这种行为，当我分配并传递 TCHAR 缓冲区时，我得到了垃圾，因为它用多字节数据填充了我的 wchar 缓冲区。
我的问题是：是否有一种干净的方法可以在同一应用程序中使用这两个库？ 我使用这些库的方式可能做错了什么吗？
I have a project that uses two third party libraries, both of which make use of TCHARs in their header files. Unfortunately one library is complied as multi-byte (call it library a), and the other is compiled as Unicode (call it library b).
Now the way I understand it is that TCHAR is replaced by the precompiler with either wchar or char depending on the build options. So when library a was compiled any method that takes a parameter of type TCHAR was set to expect a parameter of type char, and methods in library b are set to expect a parameter of type wchar.
Unfortunately my consuming application has to pick a character set too. If I pick Unicode then the header file I have included for library a tells me that the method wants a wchar, because when I compile the TCHARs in the header they are interpreted as wchars. This includes TCHARS defined inside of structures. I have confirmed this behavior in practice, when I allocate and pass a TCHAR buffer I get back garbage because it fills my wchar buffer with multi-byte data.
My questions are: Is there a clean way to consume both of these libraries in the same application? Am I maybe doing something wrong with how I'm using these libraries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
假设您在这些库之一中没有使用太多类/函数，我将完全包装其中一个库。 假设您决定在应用程序中使用 mbc 并包装库 b (unicode)，则您的包装器头文件可以使用
wchar_t而不是TCHAR，因此 #define 不会影响您的界面。 在包装器的 cpp 文件中，您 #include 库 b 的标头，您 #defineTCHAR来匹配库 b。 除了包装器之外，不应允许任何代码查看库 b。如果您在这两个库中使用多个类/函数，那么维护包装器代码将很快成为一个问题。
Assuming you're not using too many class/function in either one of these libraries, I would wrap one of the library completely. Let's say if you decided to use mbc in your app and wrap library b (unicode), your wrapper header file can use
wchar_tinstead ofTCHARso #define will not affect your interface. Inside your wrapper's cpp file where you #include library b's headers, you #defineTCHARto match library b. No code other than your wrapper should be allowed to see library b.If you're using more than a few class/function in both of these libraries, maintaining the wrapper code will quickly become a problem of its own.
正如叶成行 建议，最好将差异包装在您自己的 API 中。 这使得您的源代码独立于它。
然后，包装 API 必须将字符从您的编码转换为库的编码。 在 Windows 上，我有名为 WideCharToMultiByte 等的函数。
As Shing Yip suggested, better wrap the difference in an API of your own. This makes your source code independent of it.
The wrapping API then has to convert characters from your encoding to the library's. On windows, I you have functions called WideCharToMultiByte and the like.
我认为你最好的选择是选择库 a 或库 b（在本例中我们将说库 a）来执行此操作。 然后，当您包含库 b 头文件时，请确保 #define/#undef 无论编译库 b 时使用什么。 然后，您必须确保在库 a 和库 b 使用相同数据时在它们之间进行转换。
如果您能以相同的方式编译它们，那就太好了。 不然会很乱。
I think your best option is to choose either library a or library b (we'll say library a for this example) way of doing it. And then when you include library b header files, make sure you #define/#undef whatever library b was compiled with. Then you have to make sure you convert between library a and library b anytime they use the same data.
It would really be best if you could get them compiled the same way. Otherwise it's going to be very messy.