[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: C++ thoughts for Berlin

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 29 May 2013 18:03:17 -0700

On 05/29/2013 05:48 PM, Justin Erenkrantz wrote:
> On Wed, May 29, 2013 at 12:05 PM, Blair Zajac <blair_at_orcaware.com
> <mailto:blair_at_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.

Received on 2013-05-30 03:03:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.