For those who come after me, rebuilding libxerces-c using char16_t is
relatively easy. Here's how I did it on Ubuntu 14.04:
> apt-get source libxerces-c3.1
> cd xerces-c-3.1.1
edit configure.ac to apply this patch:
289c289
< xerces_cv_type_xmlch=$xerces_cv_type_u16bit_int
---
> xerces_cv_type_xmlch=char16_t
> export DEB_CXXFLAGS_SET="-std=c++11 -fPIC"
> dpkg-buildpackage -rfakeroot -b
Whether installing such a package is a good thing for your system or
not is another matter, since I guess it will break binary
compatibility between libxerces-c and anything else that depends on
it; I haven't been game to reboot my system yet.
Regards,
Tom
On Fri, Sep 19, 2014 at 8:06 PM, Tom Cook <tom.k.c...@gmail.com> wrote:
> Thanks for responding.
>
> Yes, use of C++11 char16_t would mean that various compilers would
> become unsupported (ie GCC support would change from 3.4.x+ to 4.5+).
>
> I've just tried this patch on configure.ac:
>
> 289c289
> < xerces_cv_type_xmlch=$xerces_cv_type_u16bit_int
> ---
>> xerces_cv_type_xmlch=char16_t
>
> but the results are more-or-less disastrous (haven't had a chance to
> look into the errors in detail yet). Is that the right way to try
> changing the type of XMLCh?
>
> Thanks,
> Tom
>
> On Fri, Sep 19, 2014 at 5:50 PM, Alberto Massari
> <albertomass...@tiscali.it> wrote:
>> There are no plans to use C++11 features in Xerces, especially if this would
>> make any of the supported compilers to become unsupported.
>> But you can make a test to see if char16_t literals are encoded in the same
>> format as XMLCh expects...
>>
>> Alberto
>>
>> Il 19/09/14 08:56, Tom Cook ha scritto:
>>
>>> No response to this so far. Am I better off rebuilding Xerces-C with
>>> XMLCh typedef'd to char16_t?
>>>
>>> Regards,
>>> Tom
>>>
>>> On Mon, Sep 15, 2014 at 4:16 PM, Tom Cook <tom.k.c...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've googled around and found this question asked in quite a few
>>>> places, but not any answer to it.
>>>>
>>>> What is the best way of handling strings, and particularly string
>>>> literals, in portable code?
>>>>
>>>> Specifically, I'm interested in building code with VC++ 2013 on
>>>> Windows and G++ 4.8 on Linux. On Windows, the Xerces binary build
>>>> uses wchar_t as the character type, and so, naturally enough, people
>>>> on Windows write code that passes around wchar_t. Unfortunately, G++
>>>> has a 4-byte wchar_t and so Xerces uses unsigned short int (or
>>>> uint16_t) as its character type. This causes all such code written
>>>> for Windows to break in fairly horrible ways on Linux, and in ways
>>>> that require wide-ranging code changes to fix.
>>>>
>>>> So far, the best solution I've come up with looks something like this:
>>>>
>>>> #if defined _MSC_VER
>>>> #define U16S(x) L##x
>>>> typedef wchar_t my_u16_char_t;
>>>> typedef std::wstring my_u16_str_t;
>>>> typedef std::wstringstream my_u16_stream_t;
>>>> inline XmlCh* XmlString(my_u16_char_t* s) { return s; }
>>>> inline XmlCh* XmlString(my_u16_str_t* s) { return s.c_str(); }
>>>> #elif defined __linux
>>>> #define U16S(x) u##x
>>>> typedef char16_t my_u16_char_t;
>>>> typedef std::basic_string<char16_t> my_u16_str_t;
>>>> typedef std::basic_stringstream<char16_t> my_u16_stream_t;
>>>> inline XmlCh* XmlString(my_u16_char_t* s) { return
>>>> reinterpret_cast<char16_t*>(s); }
>>>> inline XmlCh* XmlString(my_u16_str_t* s) { return XmlString(s.c_str()); }
>>>> #endif
>>>>
>>>> But of course this still requires major code changes for existing code
>>>> that uses wchar_t.
>>>>
>>>> Is there a better way of sorting this out? C++11 now has a distinct,
>>>> UTF-16-encoded character type, char16_t. Is there any plan to make
>>>> Xerces use it?
>>>>
>>>> Thanks,
>>>> Tom
>>
>>
>>
>> --
>> -----------------------------------------
>> Lucia Riccardi & Alberto Massari
>> Via Prasca 19/5
>> 16148 Genova
>> Italia
>> Tel.: (010) 3771653
>> E-mail: lucia_albe...@libero.it
>> Web: http://www.massari.org
>>
