On 23/01/18 14:59, Mark Douglas wrote:
Hi Roger,
I think Microsoft have had wchar_t as a type way before char16_t was introduced
(as far back as I can remember, which is getting shorter as I get older :)). At
the time, Microsoft were well known for doing things the 'Microsoft way' and
not following standards very well. So maybe they backed themselves into a
corner to some extent.
Indeed, your suggested edit has worked! I now have XERCES_XMLCH_T defined as
wchar_t :)
That's great to hear.
I'm not quite sure why I'd need a transcoder if I'm using wchar_t across the
board, so hopefully I can get away with having to worry about it. The only XML
files we consume are UTF-8, so everything *should* just work. Fingers crossed.
For the most part, it's unlikely to be used unless you have some
non-UTF-8 input. Not sure if it's used for UTF-8/UTF-16 conversions.
If you would like to give it a try,
https://issues.apache.org/jira/browse/XERCESC-2132 now has a patch
attached, or you can download directly from the linked github branch.
Just add "-Dxmlch-type=wchar_t" when running CMake.
I'm going to push my luck a bit here and ask an unrelated question. I need to
build both 32 and 64 bit binaries for our application (it's a long story), but
the Xerces C++ CMake system generates .LIBs and .DLLs with the same name. Is it
possible to specify that one or other of the builds generates different output
filenames? For example, I'd like to generate a xerces-c_3_2x64.dll for my
64-bit build. At the moment I'm having to hand-craft the generated VS project
file to achieve this.
It's certainly possible to configure CMake to add architecture-specific
suffixes. However, there would be a good bit of breakage resulting from
that--the DLL naming pattern is used by e.g. autoconf, CMake FindXercesC
and other scripts to find the library, and this would cease to work.
And there are likely many other users of the library who depend on the
stability of the existing names. As a result, I'd think keeping the
existing scheme as the default would be necessary. But, it should
certainly be possible to add an option to add a suffix to the library
names for custom builds of the library. For example
"-Dlibrary-suffix=my-suffix" or "-Dlibrary-suffix=TRUE" (for automatic
addition of architecture). Do you have any established convention for
the names of the suffixes?
My team's strategy, which matches how things are typically done on Unix
and with CMake, is to have a separate build directory for 32-bit builds
and 64-bit builds so that the names never clash even when they are
identical. The libraries are unprefixed across the board, and 32-bit
and 64-bit binaries are never mixed. Likely we'll be dropping 32-bit
builds at some point though; not sure anyone actually uses them...
Regards,
Roger
