subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: AW: C++ thoughts for Berlin
Date Mon, 03 Jun 2013 18:16:47 GMT
On 06/02/2013 10:53 PM, Markus Schaber wrote:
> Hi, Blair,
>
> Von: Blair Zajac [mailto:blair@orcaware.com]
>>> [Discussion whether to use (part of) C++ for SVN development]
>>
>> 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.
>
> I fully understand your frustration. :-)
>
> C can be frustrating. But believe me, as I used to program C++ for my day job for almost
five years, it is not the solution. Frustration just shifts from some problem areas to others,
and memory management is not really better.

I'm not sure where all the negativity for C++ memory comes from.

A colleague and myself at work wrote a multithreaded-safe C++ library 
that provides an asset API for visual effects (textures, plates, rigs, 
etc) to all the apps at work; it's either explicitly linked to or pulled 
in via a plugin everywhere, including third party apps (Maya, Nuke, 
Katana, etc).

Under the hood it uses a multithreaded C++ RPC library to talk to our 
middle-tier servers to get the assets.  The middle-tier talks to a C++ 
server that uses svn_fs and svn_repos.  The client library handles the 
parent process calling fork() and properly handling locked mutexes in 
the parent process that cannot be unlocked in the child process.  So I 
feel that its a pretty complicated library, especially when the parent 
process can do anything it wants.

The library uses shared pointers mostly everywhere, but this made it 
easy for us to code and easy for our users because we hand them a shared 
pointer, so there's no thought required on who owns the memory.  Maybe 
this design came from too much Java/Scala or Python coding ;)

The only place we had memory issues was in our C++ server using the 
svn_fs and svn_repos API, where in a C++ class, if we listed a data 
member that used pool memory before the AprPool data member that 
provided that memory, then at destruction time we could get core dump. 
The fix was to reorder the AprPool data member before all other data 
members.

So I don't get where the dislike comes from.  Maybe it's not cool to use 
shared pointers everywhere, but it was easier and got the job done and 
our users are happy.

Blair


Mime
View raw message