Hi Roger, Thank you very much for this valuable feedback! As I'm new to CMake, I didn't find the options of disabling char16_t (at least I wasn't looking for the right thing to start with!).
I think the default policy of using char16_t, if it is available, is a good choice - cross platform consistency should be maintained where possible I think. The reason for wanting to use wchar_t is that I'm moving some legacy code from Xerces C++ 1.5.1 to 3.2.0 and a LOT of the application code is using wchar_t as the character type. I've also now selected the VC++ option to 'Treat WChar_t as a Built in Type' in my application meaning that it's no longer compatible with 16-bit integer values. If I were to use char16_t for Xerces C++ I'd need to make a lot of XMLString::transcode() calls in my application to perform the conversion. Either that, or I'd have to insert a lot of reinterpret_cast<wchar_t*> etc. throughout the code. So for me, using wchar_t seems like the least invasive of the two options and also means I don't need to perform any transcoding in order to interface with the rest of the application. I think that adding an option to force wchar_t use as you suggest would be a valuable addition - at least on platform where wchar_t is 16-bit. By the way, I wasn't quite sure what the CMake '-Dtranscoder=windows' option did. Kind regards, Mark -----Original Message----- From: rle...@codelibre.net [mailto:rle...@codelibre.net] Sent: 23 January 2018 13:57 To: c-users@xerces.apache.org Subject: Re: How to build with XMLCh = wchar_t on Windows platform. 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
