Roger Leigh <rle...@codelibre.net> writes: > I'm not entirely sure how to class code written using L"". It's not really > portable, being Windows-only as you say (Windows being the only platform > where wchar_t is 16-bit and usable as XMLCh). And it's not strictly portable > even to different builds of Xerces-C, given that XMLCh is configurable and > that wchar_t isn't even the default (char16_t is the default for C++11 and > above).
>From experience dealing with clients, there are applications that only need to target Windows and they use L"" strings liberally. Still, I think the benefits of switching to char16_t outweighs this drawback. > These both make sense. For the networking side, I think we could also argue > the case for the MacOS accessor as well (cfurl), so long as it supports > SSL. The problem with MacOS-specific accessor is that I believe it requires linking a framework which make things messy (static linking on user side, pkg-config, etc). But if there is strong desire to have it, I am fine with that, especially if the default is "no network". > >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). > > I'm on slightly more recent versions, as is the AppVeyor and Travis CI, but > so long as we can agree on the required C++ subset we can identify the > minimum version requirement. That would probably require quite a bit of effort. As in, are we going to create a document listing every C++11/14 feature we are allowed to use (with some of them having multiple semantic revisions)? In this sense picking the minimum versions of the three major compilers and saying that any commit that compiles and works with these is fair game is a lot simpler and crispier criterion. Though that would mean we need to have these versions always available for CI (not sure how doable that is with AppVeyor and/or Travis CI). > >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. > > It does, see https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html > > We currently have it set like this: > https://github.com/apache/xerces-c/blob/master/CMakeLists.txt#L37 : > > # Try C++17, then fall back to C++14, C++11 then C++98. Used for > feature tests > # for optional features. > set(CMAKE_CXX_STANDARD 17) > > CMAKE_CXX_STANDARD sets the requested standard version. If unavailable, it > will fall back to earlier standards. Since Xerces-C++ doesn't have a > minimum standard at present, we allow it to fall back without restriction > and then do specific feature tests to see what's available. If we require > C++14, we will need to add > > set(CMAKE_CXX_STANDARD 17) > > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > in order to mandate C++14. It will then fail if it is not possible to > achieve this. You probably meant to write `set(CMAKE_CXX_STANDARD 14)` here, right? > What I do in my projects is something like this: > > # Prefer C++17 support > if(NOT CMAKE_CXX_STANDARD) > set(CMAKE_CXX_STANDARD 17) > set(CMAKE_CXX_STANDARD_REQUIRED FALSE) > endif() > > This is to permit the user to override it, and only default if unset. There is no special `latest` value or some such for CMAKE_CXX_STANDARD? If not, I guess something like this will have to do: if(NOT CMAKE_CXX_STANDARD) set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_STANDARD_REQUIRED FALSE) endif() We will then have to keep updating it to make sure Xerces-C++ is compatible with the latest standard. --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
