On 29.05.2013 21:05, Blair Zajac wrote:
> Given I won't be at the Berlin hackathon, here's my thought on the C++
> topic .
> I'm generally in favor of a move to C++, it would be nice to get
> features that we work around now in C.
> 1) How old g++ do we maintain? We have RHEL 6 boxes that have 4.4.6,
> so we wouldn't be able to use nice C++ 11 features.
C++11 is out of the question anyway -- for the exact same reasons that
we still require C90, even though the C99 standard was effectively
compete when Subversion development started back in Y2K. (And that
turned out to be a very good decision because our most important
platform's vendor still does not -- and never will -- support C99).
> 2) Which libraries can we leverage? I use Boost and have no issues
> pulling that in, but I except some people do, given what I hear about
> Boost (although I'm a fan). RHEL 6 comes with Boost 1.41.0.
I would only ever use Boost as a compatibility wrapper for certain smart
pointer features that are not available in the C++98 standard, and even
then I'd import only the specific headers that implemented them and
nothing else. And nothing newer than 1.49 even then, newer versions
don't work on the majority of compilers I use daily.
Because here's the thing: without properly implemented smart pointers,
exception-safe memory management in C++ is practically impossible.
auto_ptr<> from C++98 is a joke and should be avoided like the plague,
so Boost is effectively the only option.
> 4) We use the Google C++ style guide  at work for all our C++
> coding, dropping the ban on exceptions. Would we use that? Maybe we
> want to keep our code exception free, if we can?
Here's the thing -- writing exception-safe C++ code is /really/ hard.
I'm pretty sure half of our regular devs couldn't do it without a year
in a reorientation camp -- and that's a compliment, because I didn't
say three years :)
Even for something as conceptually simple as
it took me a couple weeks to get to the point where I'm reasonably sure
that it won't leak memory when an exception is thrown.
But I'm not strictly against using C++ where it makes sense. For
example, a while ago I talked with Greg about using LevelDB for a
next-generation metadata index for a filesystem backend implementation.
Since LevelDB is C++, obviously the glue code around would have to be,
as well. I also started (very slowly and tentatively) on a C++ API and
object model which, I hope, we might someday use as the basis for all
our script bindings.
But I'd never recommend rewriting parts of our code in C++; that'd make
our 18-month release cycle for 1.8 look like a half-day holiday in
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-05-30 03:22:19 CEST