On 06/02/2013 10:53 PM, Markus Schaber wrote:
> Hi, Blair,
>
> Von: Blair Zajac [mailto:blair_at_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
Received on 2013-06-03 20:17:29 CEST