Open file in TagLib with Unicode chars in filename

I am quite new to the C++ 'area' so I hope this will not be just another silly 'C++ strings' question.

Here is my problem. I want to integrate TagLib (1.5, 1.6 as soon as I manage to build it for Windows) into an existing Windows MFC VS2005 project. I need it to read audio files metadata (not write).

The problem is that the program stores the input file names using CString(), and it has the Unicode option turned on (so the default chars are "wchar_t"). The reason for this (I think, the project was started by someone else) is that some of the 'input' file names could contain Unicode charaters (for example, Japanse or Arabic characters).

For example, the file path is something like "d:\docs\audio_test\stragecharڝhere.mp3", but I get it with:

CString fpath = tmpFile->GetFilePath();

Now.. if I try to do:

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

I get something like:

unresolved external symbol "__declspec(dllimport) public: __thiscall TagLib::FileName::FileName(wchar_t const *)"

If I try something like:

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

I get rid of the compilation errors, but "f" is an invalid pointer/object..开发者_如何学运维 and when I try reading a tag, I receive an assert failed.

So, can anyone give me some pointers on how should I pass that CString, in it's Unicode form, to the TagLib ?

Update: TagLib address: http://developer.kde.org/~wheeler/taglib.html

Thank you,

Alex

It's possible that the problem is caused by the issue described here. Basically MSVC has an option to treat the wchar_t type differently, which causes the compiled library is not binary compatible with an application compiled without that option. Unfortunately the CMakeLists.txt build file enables the /Zc:wchar_t- option by default. I'd try to edit the file, remove the option and re-compile TagLib. Ideally version 1.6, as it contains a lot of bug fixes.

I missed something essential when I first read your post, so here is another, new and improved answer:

The error comes from the linker, not the compiler. It thus seems that TagLib::FileName does have a ctor taking wchar_t const*, but the problem is that you don't link with the library implementing it, or link with a version of the library that does not include it.

IIUC, this library comes from the Linux world (where file names are expressed as char arrays), and was later ported to Windows (where file names are expressed as wchar_t arrays). The FileName ctor taking a wchar_t array is thus probably conditionally compiled on Windows (i.e., inside #ifdef _WIN32 or something similar), and the library you are linking with (if you are linking the library) was not compiled with the same preprocessor defines.