On 2018-01-23 12:03, Mark Douglas wrote:
Hi,
This is my first mail to this group, so hopefully I've come to the
correct place!
Yes, it is!
I'm currently attempting to build and use Xerces C++ 3.2.0 in my
application, but I'm having an issue where XMLCh is defined as
char16_t (not compatible with wchar_t). From what I've read, I'd
actually like XMLCh to be defined as wchat_t instead. My code will
only ever be run on Windows, so no fear of cross platform
incompatibility.
As I understand it, if XMLCh is defined as wchar_t, I won't see any
errors in my own code where the compiler can't convert from XMLCh* to
wchar_t* etc.
So my questions are as follows:
1. Is wchar_t something that is still supported by Xerces C++?
Yes. In cmake/XercesXMLCh.cmake we check for char16_t and wchar_t
support. We default to using a 16-bit integer type i.e. uint16_t, but
enable char16_t if available, and on Windows we fall back to wchar_t if
char16_t is unsupported (on other platforms wchar_t is 32-bit an
unsuitable). Most non-Windows platforms will be using uint16_t, or
char16_t if using a new compiler (and cmake).
2. What's the correct way of defining XMLCh as wchar_t instead
of char16_t? I changed the definition of XERCES_XMLCH_T in
Xerces_autoconf_config.hpp, but then not all of the tests compiled.
I'm guessing I need to do something in one of the CMake files?
The above file would be the place to do so. Just add
set(HAVE_STD_char16_t FALSE)
after the check.
3. Are there any real reasons why I shouldn't attempt this?
No, it's absolutely still supported. One thing we might want to do here
is to add an option to allow the use of wchar_t to be forced, so you
could configure with e.g. -Dxmlch=wchar_t or -Dxmlch-char16_t=OFF.
An interesting question is what the default policy should be.
- Using wchar is good for compatibility with older Visual Studio
versions and other Windows APIs
- char16_t is good for cross-platform compatibility since we have the
same XMLCh type on all modern platforms, and we can also use Unicode
string literals directly in our sources e.g. u"A UTF-16 string", which
makes using Xerces-C++ vastly more pleasant.
I'd be interested to know your requirements for needing to use wchar_t.
Also, for anyone else using char16_t/wchar_t what your needs and
preferences are. Portable Xerces-C++ programs should work transparently
with either, up to the point you need to pass the strings to other
library APIs.
Kind regards,
Roger
