subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: C++ thoughts for Berlin
Date Sat, 01 Jun 2013 23:23:22 GMT
On 5/29/13 6:17 PM, Justin Erenkrantz wrote:
> On Wed, May 29, 2013 at 6:03 PM, Blair Zajac <blair@orcaware.com
> <mailto:blair@orcaware.com>> wrote:
>
>     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.
>
>
> I don't see how you can have a clean C++ implementation as we expose pools in
> the C API.  I just think we're going to bring a world of hurt upon us all if we
> try to do a wholesale rewrite of C++ and try to shove the pool model into it.
>   (The batons and callbacks all require pools with a certain lifetime - so there
> are third-party code that is relying upon the pool hierarchy being correct.)
>
> If we really wanted to go that route, the far saner (if you can call it that)
> approach is to just call it Subversion 2.0 and have a pool-free external
> API...from where I sit, I don't see much value going that far - how many years
> do we want to dedicate to 2.0?  Are things ultimately so broken that we simply
> can't make Subversion better unless we go to C++?  It's not a zero-cost item.

I agree it's not worth going to C++.  Where I'm coming from is a frustration on 
the number of times I've seen pool lifetime bugs get fixed and it would be great 
to be in a language where one doesn't need to worry about that, or as much.

Blair


Mime
View raw message