Jump to content
Sign in to follow this  
Yves

C++11 Migration: Discussion

Recommended Posts

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by lmat

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :D

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...