On 26/04/2017 01:30, Cantor, Scott wrote:
On 4/25/17, 3:17 PM, "Roger Leigh" <rle...@codelibre.net> wrote:

That said, I'd not be averse to including support for standard C++;
using Xerces is often a bugbear due to its age.  All our code is now
C++11, with RAII wrappers to make Xerces play nicely.  Primarily the
lack of RAII, non-standard exception types, odd memory management
semantics and transcoding all input.

The problem with C++11 is it's just not portable to enough compilers outside of 
Windows. I'm aware gcc probably supports it but gcc on actual Linux distros 
that people still use heavily does not. If I can't build it on RH6 it's not 
usable for me, and since I'm the one doing most of the work right now...

Really, C++11 is beside the point. Simply good old C++ would fix many issues, 
but this code dates to back when using real C++ and the STL was just too 
non-portable, along with the usual Unix anti-C++ bias.

Agreed that just moving up to C++98 standard types in and of itself would be greatly beneficial. There should be no portability barrier to achieving that.

Regarding portability, I also have the "pleasure" of supporting code on CentOS 6. I don't know if you've tried it, but we switched to using the SCL "devtoolset-3" (now "devtoolset-4") packages which backport a modern GCC and the rest of the toolchain to CentOS6 (and 7). We use this to build C++11 code on CentOS 6, and it's been trouble free for us. Apart from CentOS, we build C++11 without any trouble on current FreeBSD 10/11, MacOS X 10.9+, Ubuntu 14.04/16.04 and Windows (VS2013, 15, 17 soon). It's CentOS 6 which is currently the lowest common denominator; everything else has supported C++11 well for many years at this point. Our projects made the switch a few months back once they were buildable and supportable across the board.


To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Reply via email to