0

我对 C++“领域”很陌生，所以我希望这不仅仅是另一个愚蠢的“C++ 字符串”问题。

这是我的问题。我想将TagLib（1.5、1.6，一旦我设法为 Windows 构建它）集成到现有的 Windows MFC VS2005 项目中。我需要它来读取音频文件元数据（而不是写入）。

问题是程序使用 CString() 存储输入文件名，并且它打开了 Unicode 选项（因此默认字符是“wchar_t”）。这样做的原因（我认为，该项目是由其他人启动的）是一些“输入”文件名可能包含 Unicode 字符（例如，日文或阿拉伯字符）。

例如，文件路径类似于“d:\docs\audio_test\stagecharڝhere.mp3”，但我得到它：

CString fpath = tmpFile->GetFilePath();

现在..如果我尝试这样做：

TagLib::FileRef f(fpath.GetBuffer(0));
fpath.ReleaseBuffer();

我得到类似的东西：

未解析的外部符号“__declspec(dllimport) public: __thiscall TagLib::FileName::FileName(wchar_t const *)”

如果我尝试类似：

TagLib::FileRef f(reinterpret_cast<char*>(fpath.GetBuffer(0)));
fpath.ReleaseBuffer();

我摆脱了编译错误，但“f”是一个无效的指针/对象。当我尝试读取标签时，我收到一个断言失败。

那么，谁能给我一些关于我应该如何将 Unicode 形式的 CString 传递给TagLib的指示？

更新：TagLib 地址：http://developer.kde.org/~wheeler/taglib.html

谢谢，

亚历克斯

4

2 回答 2

3

问题可能是由此处描述的问题引起的。基本上，MSVC 有一个选项来区别对待wchar_t类型，这导致编译的库与没有该选项编译的应用程序不兼容。不幸的是，CMakeLists.txt构建文件默认启用该/Zc:wchar_t-选项。我会尝试编辑文件，删除选项并重新编译 TagLib。最好是 1.6 版，因为它包含许多错误修复。

于 2009-10-06T16:16:12.260 回答
1

当我第一次阅读您的帖子时，我错过了一些重要的东西，所以这里是另一个新的和改进的答案：

错误来自链接器，而不是编译器。因此，似乎 TagLib::FileName确实有一个ctor wchar_t const*，但问题是您没有链接到实现它的库，或者链接到不包含它的库版本。

IIUC，这个库来自 Linux 世界（文件名表示为char数组），后来移植到 Windows（文件名表示为wchar_t数组）。因此，采用wchar_t数组的 FileName ctor 可能在 Windows 上（即内部#ifdef _WIN32或类似的东西）有条件地编译，并且您正在链接的库（如果您正在链接库）没有使用相同的预处理器定义进行编译。

于 2009-10-06T15:02:42.067 回答