Ape tags, includes and portability

Sebastian Pipping webmaster at hartwork.org
Tue Jul 18 16:28:10 CEST 2006

Lukáš Lalinský wrote:
> Sebastian Pipping wrote:
>> My last mail regarding windows/linux portability
>> for the official taglib code was ignored which
>> is a "no" in my eyes. If this portability way
>> is not wanted I can accept it and build the fourth
>> windows port around but in my eyes this is not
>> the best solution. The code would not really get
>> more complicated than before: Here is an example line
>> d->file = PORT_FOPEN(file, d->readOnly ? _PT("rb") : _PT("rb+"));
>> which fully works on Unix, both Ansi and Unicode Windows.
> Well, you need to compile two versions of the library in order to support both
> Ansi and Unicode API on Windows, and can't use both in one application (for
> compatibility reasons).
> There are three ways how it could be done, with support for both APIs:
> * Windows-like way of doing this would be having two
> TagLib::File contructors, one for wchar*, one for char*.
> * Glib-like way, and using UTF-8 for file names.
> * And one more option would be using TagLib::String instead of char*.
> I'd love to if TagLib 1.5 would include any of these solutions, but I really
> don't like having it either Ansi-only or Unicode-only. In that case I'd have to
> keep my own UTF-8 branch. :(

i thought about your recommendations and i now strongly
prefer the first one, the two-constructors-solution.
this would save unnecessary conversions on windows and
also not require two differently compiled versions.
TagLib::String is not what i want since i mainly work
with plain-c-"array"-strings.

so if we agree now let's go for taglib 1.5...


Sebastian Pipping

More information about the taglib-devel mailing list