C++11 Migration: Discussion

[Yves]

This thread is for discussions and opinions about the C++11 migration. The ticket (2669) should be used for documenting facts, decisions and tasks.

My personal opinion is that we should make the move now. Because it's just a matter of time, most of the contra arguments don't really matter.

It's better to get used to the new coding style early.

Also I'd like to continue with my work on SpiderMonkey and not doing the migration would interrupt that abruptly. I'm not happy that a third party library puts pressure on us this way, but it's a question of what alternatives we have. Staying on V24 would be bad and switching to another scripting engine or even another script language like Lua has been discussed and discarded before.

[Stan`]

Is a 1-3% improvement worth the change ?

[sanderd17]

We can't stick with outdated libraries. So we need to update anyway.

Letting our code get outdated, and updating suddenly results in the amount of work Yves had to do for the previous upgrade. So it's easier if we support SpiderMonkey v31 as soon as possible.

[Yves]

Is a 1-3% improvement worth the change ?

That alone would definitely not be worth the change.

I shouldn't have listed that first, the order of pro and contra points in the ticket is completely random.

[wraitii]

Good move imo, the new syntaxes are interesting and it's not that big a change.

[historic_bruno]

It's too bad SpiderMonkey isn't interested in backward compatibility (though, who is really surprised?), that is really the only argument that matters. If they started requiring clang tomorrow, we would have to as well, I suppose Everything else is only justifying that necessity.

[wraitii]

A quick guide to what C++11 can offer us (near the bottom): http://isocpp.org/wiki/faq/

Stuffs like "auto", decltype and range-for statements can improve readability. Lambda improves usability and readability. Proper usage of "move" can avoid using pointers when they should not be needed, and can help with memory management in some algos. Initializer_lists are more convenient and improve readability. It also cleans initing up a bit. Usage of "nullptr" instead of "NULL" could help us alleviate some issues with uninitialized stuffs.

There's also improvements to types, and more structs can be recognized as POD (I'm fairly sure we have a few of those). You can also force arrays to be aligned as whatever you want, though I doubt we'd see the use for that.

There's also language static asserts, so we will be able to ditch our macros for that, and these kinds of conveniency.

Finally the STL has been revamped with convenient things like initializer lists, the move operator (good example of how a simple syntax works better now), more functions, the "unique/shared/weak_ptr" family, and we also get some useful new ones such as unordered_set and unordered_map, for which we would have had to rely on boost. And std::array if you want to.

[niektb]

I also learned that C++11 has a better multithreading support.

[lmat]

Is a 1-3% improvement worth the change ?

Definitely not. This change, as I see it, has nothing to do with performance increases (except those that come with the new version of Spider Monkey).

The reasons I see for going to c++11:

Because we use c++03, and c++11 is the next version of the standard. It's been a few years, the language is widely supported now, and has shown itself to be a major advancement. For instance, any team that's still using RCS should probably consider moving to a newer VCS just because RCS is old and has been greatly improved. It's not the *best* tool for *any* job, and is in

So that we can take on the new version of Spider Monkey. If Spider Monkey went Clang-only, we would have to consider more closely, but c++11 is an obvious place to go from where we are (c++03).

C++ has loads of new features that are very useful to us covering usability: lambda statements, universal initialization, auto, "for-each" for loop syntax; optimizations: move semantics (including "perfect forwarding"), right-hand references, "standard" threading support (this may not be an optimization over pthreads, but I think it's good); and other functionality: POD types expanded, random number generation is improved.

[EDIT]

Oh yeah, c++11 is largely (completely?) backward compatible. Compiling a c++03 program as c++11 should have no problems, and any new warnings that show up will only serve to improve the code.

Edited July 11, 2014 by lmat

[auron2401]

That alone would definitely not be worth the change.

I shouldn't have listed that first, the order of pro and contra points in the ticket is completely random.

That alone WOULD be worth a change.

Performance. is. everything. 2 frames can be the difference between a disgruntled user or a happy one.

[sanderd17]

3% is way less than 2 frames. And performace isn't everything. If we wait long enough without developing, it will be performant some time thanks to newer hardware

[Clovisnox]

Like said before, further than the pro/cons list we don't actually have a choice if we want the developpement to keep going forward on the long term

[scroogie]

The thing with performance improvements is that they often only change performance by a small margin, 1% say, but if you do that in a hundred commits, it adds up.

And i've often seen it working like that. You benchmark / profile, address one issue giving you 1% gain, then you benchmark/profile again, and address another hotspot, etc.

But anyway, this is actually quite offtopic here.

Just out of curiosity, what *are* the actual disadvantages of doing the move? I think even on LTS distributions like RHEL its no problem to install e.g. gcc 4.7 in case its required.

[sanderd17]

Just out of curiosity, what *are* the actual disadvantages of doing the move? I think even on LTS distributions like RHEL its no problem to install e.g. gcc 4.7 in case its required.

The disadvantage is indeed compiler support. Not only for Linux. But some people still have older Visual Studio versions. Like our autobuild also uses an old VS version. The autobuild is also kinda hard to update, and it should be completely redone with the possibility to extend to CI testing, and with the server move coming somewhere in the (hopefully near) future. A lot of work like that requires some thinking first.

[Ykkrosh]

I think even on LTS distributions like RHEL its no problem to install e.g. gcc 4.7 in case its required.

To integrate properly and straightforwardly with distro package managers, we should only use the default compilers in the distros we care about, which I think currently means GCC 4.6 (for Ubuntu 12.04).

On Windows, VS2010 should be sufficient for compatibility with SpiderMonkey (since I think that's what Mozilla still uses), but many of the more interesting C++11 features are only available in VS2012 or VS2013. One problem there is that VS2012 won't run on WinXP, so any developers currently using WinXP (I've got data that suggests there's still a few) will have to upgrade to Win7 or above. (Players can still use XP, this only affects people wanting to compile the code). Is there anyone here who would be seriously affected by that?

Also, updating VS would be a bit of a pain for e.g. me, since I use Visual Assist (and can't stand VS without it) but only have a license for a VS2010 version. And the VS2012/2013 IDEs have a terrible UI design (uppercase menus, really?). Those aren't blocker issues, but they are downsides.

[Yves]

One problem there is that VS2012 won't run on WinXP, so any developers currently using WinXP (I've got data that suggests there's still a few) will have to upgrade to Win7 or above.

I wouldn't worry about supporting Windows XP, not even Microsoft supports it any more. With the rest I agree.

[Ykkrosh]

About 10% of our Windows players over the past 6 months were on WinXP (and that's about 2/3 as many players as for all versions of OS X), so I think it's important to continue supporting running the game on XP for now. I'm not too concerned about dropping it as a development platform though.

[historic_bruno]

One problem there is that VS2012 won't run on WinXP, so any developers currently using WinXP (I've got data that suggests there's still a few) will have to upgrade to Win7 or above. (Players can still use XP, this only affects people wanting to compile the code). Is there anyone here who would be seriously affected by that

At least one of them is my old laptop

[lmat]

To integrate properly and straightforwardly with distro package managers, we should only use the default compilers in the distros we care about, which I think currently means GCC 4.6 (for Ubuntu 12.04).

Also, updating VS would be a bit of a pain for e.g. me, since I use Visual Assist (and can't stand VS without it) but only have a license for a VS2010 version. And the VS2012/2013 IDEs have a terrible UI design (uppercase menus, really?). Those aren't blocker issues, but they are downsides.

We care about Ubuntu 12.04? I don't think Canonical does... The next LTS is out and has been for a while. I'm a very late adopter, and I'm already on 14.04 :-).

[Yves]

We care about Ubuntu 12.04? I don't think Canonical does... The next LTS is out and has been for a while.

Users of 12.04 LTS will be offered the automatic upgrade when 14.04.1 LTS is released, which is scheduled for July 24th.

source: http://fridge.ubuntu.com/2014/04/17/ubuntu-14-04-trusty-tahr-released/

[Josh]

The reality is that we have to switch to C++11 if we want to use updated libraries and that our C++11 feature set will be limited because people (including me) will still compile on GCC 4.6/VS 2010.

[Ykkrosh]

We care about Ubuntu 12.04? I don't think Canonical does... The next LTS is out and has been for a while. I'm a very late adopter, and I'm already on 14.04 :-).

12.04 is supported by Canonical for 5 years, i.e. until 2017. Over the past 6 months we had roughly the same number of players on 12.04, 13.10, and 14.04 (~3000 on each, who enabled the feedback feature). That time period overlaps the release of 14.04, so there would probably be different results if we waited another few months and checked the latest data again, but it suggests there's likely still a significant number of people on 12.04 today. So we shouldn't drop support for 12.04 without significant benefits (and I don't think there are any significant benefits here, since 12.04 / GCC 4.6 should be good enough for the SpiderMonkey upgrade).