On 5/29/13 6:17 PM, Justin Erenkrantz wrote:
On Wed, May 29, 2013 at 6:03 PM, Blair Zajac <bl...@orcaware.com <mailto:bl...@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
