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
Charmed Quark Systems, Ltd

-----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.


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

Reply via email to