views:

328

answers:

2

Hello,

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

+1  A: 

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.

Éric Malenfant
Indeed, the library was ported from *nix to windows. And, indeed, it uses some #ifdef to 'select' the data types depending on the platform.At some point, I will have to compile it myself for windows (the lastest version), as now I was using the precompiled 1.5 MSVC version.I will try again to use it the - for now, the priorities have changed for the project :)Thank you
Alex
+3  A: 

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.

Lukáš Lalinský
Hello, thanks for the info. Indeed, I will have to compile version 1.6 for windows, because I'm interested specifically in the mp4 tag support (which was added in 1.6). For the moment I was just testing out 1.5 - the binary version compiled (with/for MSVC).Thank you
Alex
This answer popped up #1 on google when I had the exact same problem. Killing the /Zc:wchar_t- was exactly what I needed. Thanks!
Kyle