I would have been writing the original version of the parser in about 98 probably, so C++98 would have only just come into being. Though, the thing with not just sharing allocated memory with the containing application was added later. I didn't write it that way at the start and wouldn't have ever went that way myself.
There definitely wasn't any Unix anti-C++ bias in the original code, since I'm a Windows guy and had been doing C++ for quite a few years by then. But to support the 9ish or more platforms we did at the time without any conditional code (other than the per-platform stuff and some endian sensitive code I guess), meant keeping it pretty plain jane. -------------------------------------------- Dean Roddey Chairman/CTO Charmed Quark Systems, Ltd www.charmedquark.com -----Original Message----- From: Roger Leigh [mailto:rle...@codelibre.net] Sent: Wednesday, April 26, 2017 4:04 AM To: c-dev@xerces.apache.org Subject: Re: Integrating CMake support for xerces 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. Regards, Roger --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
