Hi Roger, Thanks for getting the ball rolling. See my comments below.
Roger Leigh <rle...@codelibre.net> writes: > One of the issues I encountered was difficulty in building on modern > platforms, Windows in particular, which was the impetus for developing > the CMake build now incorporated officially in the Xerces-C 3.2.x > releases. I would suggest we drop support for autotools in 4.0.0. I personally view both (autotools and CMake) as pretty bad and I don't see a reason to maintain two bad options. > These are too deeply entrenched to consider removing at this point, but > C++11 brings native char16_t and char32_t character types which could > alleviate some of the problems. Agree. Do you know what's the story with char16_t vs wchar_t on Windows? Specifically, will (Windows-only) codebases that pass L""-strings to Xerces-C++ API need to be changed? > With a switch of XMLCh to char16_t, this would enable direct use of unicode > string literals. [...] This is a complete replacement of most use of > XMLUniDefs constants in the source tree with C++11 literals. Sounds great! > * having exceptions derive from std::runtime_error; existing types can > remain compatible with wide strings > > * support use of streams, including stringstreams, directly with Xerces e.g. > InputSource, perhaps as a set of adaptors > > * where the C++ language and standard replace functionality in Xerces, it > would be worth considering replacement where there is a benefit; language > thread support might come under this category Sounds great! If we require C++11 (or later), I see no reason not to switch to std::thread & friends. > On the maintainability side, I'd like to reduce the number of configuration > options to keep testing and support within reason. Agree. One thing that I would like to keep is the ability to build Xerces-C++ without any third-party library dependencies. > * We have three message loaders and three sets of translations for en_US, > but no other translations. Some or all of them might be worth thinking > about dropping given the complete lack of utility these provide. To me keeping only ICU and inmemory sounds like the way to go. > * We have several network accessors. But with the modern push for using > HTTPS everywhere, should Xerces be providing its own or should we simply > require CURL or platform-specific functionality? Yes, I believe there should be only two options: no network support and CURL. There are also several transcoder options. Again, I think we should only keep the built-in stuff and ICU. > * Building with a modern compiler or using a modern IDE flags up tens of > thousands of warnings. Some can be fixed by using features like "mutable" > which previously were not universally available. It would be worth running > the codebase through clang-format and clang-tidy to clean it up stepwise. > It could well fix quite a few bugs and help improve performance and > correctness. Don't think anyone will object to that. > Finally, I should note that while the above might look quite disruptive, I'm > not suggesting any sort of API breakage at this point. I agree. I think we should be mindful of migration efforts that will be required on the user's side. Another thing worth discussing is which C++ standard we should target. I think at a minimum C++11 but perhaps we should be bold and aim a bit higher? In fact, IMO, talking about targeting a C++ standard like C++11 or C++14 is not very useful since every major C++ compiler (GCC, Clang, MSVC) completes support for the next standard over multiple releases. As a result, while compilers may not have complete support, they often include a perfectly usable subset of the features. In this light, what we found more useful is to specify the minimum versions of the three major compilers that we are willing to support and any features that are available in all three are fair game. In another project I am working on (build2) we had good results with picking GCC 4.9, Clang 3.7, and MSVC 14u3 and getting a very usable subset of C++14 (including move capture and generic lambdas). Another issue that we will need to decide on is which standard we are going to build for (at least by default) and whether we will be making it configurable. The problem here is that there is no guarantee that code built for different standards is ABI-compatible (and there are cases where the C++ standard itself broke this compatibility). As a result, the only sure way to avoid surprises is to build everything (Xerces-C++ and the application that uses it) for the same standard. For example, in build2 by default we use the latest available standard for any given compiler/version but there is also a way to override it for the entire build configuration. I am not sure if CMake has anything like this. --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
