Time for C++11?

Development
1

I'm guessing (and hearing :slight_smile: 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.

What I propose is:

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

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

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

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

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

    - 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.

Opinions?

Robin

[1] While we are at that, I suggest we also (re-)up the cmake version.
Probably hard to find a C++11 tool chain with a many-years-old cmake.

2

I'm guessing (and hearing :slight_smile: 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] c++ - How to detect C++11 support of a compiler with CMake - Stack Overflow

3

If the OpenSuSE build service idea moves forward, does that mean we can be
stricter with the requirements? Hopefully, people should be able to install
a package except if they want to try master or try a certain branch.

  --Vlad

4

I was expecting you to propose that. :slight_smile:

I'm very reluctant to rely on a cutting-edge compiler for compiling
Bro. There's really not much worse for an open-source tool than
downloading the code and then realizing that your system's compiler is
too old to handle it. I think we need to ensure that most people will
be able to directly download and compile Bro, without having to worry
about much else. My hope is that we are that point now for C++11
(potentially by skipping use of some specific features), but clang 3.4
and gcc 4.9 sound like a stretch to me ... We should probably reverse
the order of my list: survey OSs first what they ship these days, then
decide what we are fine requiring.

This looks like a nice C++11 summary for gcc 4.8 and clang 3.3:

    C++11 compiler support shootout: Visual Studio, GCC, Clang, Intel

Robin

5

For many people that might remain a matter of taste. Personally, for
example, I usually go for the source even if a project offers RPMs. So
I'm not sure I would relax requirements just because we have
more/better binaries.

Robin

6

Fair enough.

For surveying the environment, you can use DistroWatch. For example, to see which distros have gcc 4.9: http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9.0#pkgsearch

The main stragglers seem to be RHEL and Ubuntu LTS. Ubuntu 12.04 has 4.6.3 and RHEL 6.5 has 4.4.7.

I believe RHEL users can install a devtoolset, which has a more recent version installed under /opt, but we’ll have to make sure CMake checks there.

–Vlad

7

According to distrowatch:

RHEL 7 gcc 4.8.2
RHEL 6.5 gcc 4.4.7
debian 7 gcc 4.7.2
ubuntu 14.04 LTS gcc 4.8.2
ubuntu 12.04 LTS gcc 4.6.3
FreeBSD 10 gcc 4.7.3
FreeBSD 9.2 gcc 4.6.4

8

> I would go one step further: let's aim for C++14.

I was expecting you to propose that. :slight_smile:

And I knew your answer beforehand :-).

I'm very reluctant to rely on a cutting-edge compiler for compiling
Bro. There's really not much worse for an open-source tool than
downloading the code and then realizing that your system's compiler is
too old to handle it.

I fully understand the concerns regarding our users: it's unreasonable
to request manual bootstrapping of compilers or devoting extensive time
just to install Bro. My main point was from a developer pointer of view:
why drive with the handbrake on if it's not necessary.

That said, if we're well aware of the limitations of C++11, I don't see
an issue with this "compromise."

We should probably reverse the order of my list: survey OSs first what
they ship these days, then decide what we are fine requiring.

Agreed. GCC 4.8 and Clang 3.3 are hopefully well-supported by most
distributions by the end of the year.

     Matthias

9

At least for FreeBSD 10 this is wrong. By default, it ships with clang3.3 and has no gcc installed in the base system.

10

I am generally all in favor for that. The only problem I see with this is, that a number of people still seem to be using RHEL 6 or similar to run Bro - at least I think I remember a few people in the last few months mentioning that on IRC.

However, if we offer binary packages for these old systems (as Vlad mentioned in his email) that might be ok. You still can install it without fidgeting on older systems that you might have to use in production and we still get to use the new features.

11

Is it worth conducting a survey on the mailing list of what distros people are using? If we spin it the correct way (maybe something like “We’re reevaluating what distros we test and fully support”) and make it anonymous, even the corporate users might chime in.

I figure that between this discussion, and the one on revisiting our packages, having some more information would be useful.

–Vlad

12

Yeah, that's a good idea. Is anybody up for creating a SurveyMonkey or
Google Form that lists the most common OS/distros so that we can send
a link to the list?

Robin

13

I got it.

14

The SurveyMonkey logic is quite limited, but here’s a first stab:

https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5

Any major distros that I forgot? Or that I can remove?

Do we know what architectures Bro currently supports? Apart from the obvious x86 and x86-64, does it support PowerPC? Is it worth asking if there’s another architecture they’d like to see supported (maybe ARM)?

–Vlad

15

You left out Scientific Linux, and FreeBSD 8.4

16

+1 for ARM

-Gilbert

17

Well, I have this comment under "What Linux distro do you run Bro on?":
Note: Please select the "parent" distro if yours isn't listed (e.g. if
you're running Scientific Linux, select RHEL)

Is there any functional difference between Scientific and RHEL, in terms of
package versions? Since their stated goal is "as close to the commercial
enterprise distribution as we can get it," I figured it was a safe bet
leaving it off. I can certainly add it, though.

and FreeBSD 8.4

Ah, good catch. That's what I get for relying on the DistroWatch page...
Added a few more FreeBSD versions.

  --Vlad

18

Maybe you should just combine RHEL and CentOS into one entry, like this:

RHEL/CentOS/Scientific Linux

19

Good idea, thanks. Updated.

20

The last time I tried (a few months ago), Bro worked fine on arm. On the opens use build service, one of the arm builds also went through. From time to time we get people on IRC compiling it on their raspberry pi's - but those are kind of too slow to actually use it.