[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