On 05/29/2013 05:48 PM, Justin Erenkrantz wrote:
On Wed, May 29, 2013 at 12:05 PM, Blair Zajac <bl...@orcaware.com
<mailto:bl...@orcaware.com>> wrote:

    I'm generally in favor of a move to C++, it would be nice to get
    features that we work around now in C.


Rewriting even some of our core libraries to use C++ (even if it we kept
the existing C API) just doesn't seem to address any real problems that
we have.  We'd likely be having to write off support for a lot of
platforms due to the inconsistent nature of many C++ compilers on
platforms we have supported since 1.0.  I do not think this is a good thing.

With regards to libraries, I have had nothing but horrible developer
experiences with Boost - it's pretty counter-intuitive in a lot of
places; and C++11 isn't anywhere near widely supported to be considered
if we want to keep broad platform support.

Yeah, I've only had good experiences with Boost, but I mainly use scoped and shared pointers and some of the filesystem APIs.

As trying to use APR in a C++-based memory management model is fraught
with paradigm conflicts, we'd quite likely need to write a new
portability layer and new HTTP networking layer.  Fun!  (Not.)

Yup, I've had lots of issues with this. Putting C++ pool wrappers in C++ classes and having them destroy in the correct order can be tricky to get right (lots of core dumps in our internal RPC server). One of the nice things about moving to C++, assuming we don't use pools, is that one could stop thinking about memory management.

BTW, I believe that GCC is special - due to its bootstrapping
methodologies, it's only really meant to be compiled by itself - this
doesn't apply to Subversion, so I think that analogy is a bit of red
herring.

If we really switched to having core libraries written in C++, I would
forcefully argue that it has to be SVN 2 (regardless if we kept the C
API identical)...and I'd probably say we should just rename the project
to something else - it's not Subversion at that point, but something
else.  -- justin

Well, I wouldn't go that far ;) For most people, if it talks to the repo and wc, it's still Subversion.

Blair


Reply via email to