[Bro-Dev] Time for C++11?

Matthias Vallentin vallentin at icir.org
Mon Jun 23 11:13:07 PDT 2014


> I'm guessing (and hearing :-) that most of us would like to start
> using C++11 in Bro's code base. With compiler support now apparently
> broad and robust, and our 2.4 dev cycle starting, I'm thinking it may
> be a good time now to make the move.

I would go one step further: let's aim for C++14. In many ways C++11 was
just a half-hearted attempt to modernize the language. For example,
automatic return type deduction and lambdas are just incomplete in
C++11. 

>     - We decide which minimum versions of GCC and clang (and their
>       stdlibs) we need to require.

To be useful, we'd need gcc 4.9 anyway (because everything below has a
broken implementation of std::regex) and 4.9 also supports the most
important C++14 features (except for variable templates, which I think
we can live without for a while). We'd get a way with Clang 3.3 but
Clang 3.4 already has full C++14 support. Therefore, I suggest we
require GCC 4.9 and Clang 3.4.

>     - As a double-check, we survey the main OS distributions and make
>       sure they offer that by now.

Your install-clang script should give us some mileage when we use Clang,
GCC is often more tightly integrated into the distribution package
managers.

>     - We put cmake magic in place to check for these versions. [1]

Since version 3.0 CMake supports explicit feature enumeration of
available C++ features [1]. This may obviate the need of a specific
compiler version, albeit a bit of fiddling.

>     - We switch to compiling all C++ code with -std=c++11.

Or -std=c++1y :-).

>     - We allow use of C++11 features in new code.

Further, I'm sure we could replace many existing hacks and workarounds
in the existing code base.

>     - Over time, we modernize old code as appropiate. Probably just
>       ad-hoc for the most part, as we touch it; but maybe we can also
>       put some time towards systematic changes, like with some of
>       clang's transition tools.

Tools sound interesting for existing code. Looking forward, it would
also be useful to come up with a few guidelines, such as avoiding owning
naked pointers, preferring value semantics where possible, etc. 

     Matthias

[1] http://stackoverflow.com/a/20165220/1170277


More information about the bro-dev mailing list