Start using C++11 features in Widelands sources

Are there some specific feature you want to use? What do you think they will improve?

In general I do not mind to use some c++11 features, if they improve the code (e.g.: readability, maintainability). But I am against forcing a newer compiler, if c++11 feature should only be used, because we can.

I have found a nice list which g++ version is required for which feature: http://gcc.gnu.org/projects/cxx0x.html
As you can see the first features are supported by g++ 4.3, others only by the latest version (4.7), or none at all.

Also I think the hint on this list is important that c++11 is still experimental. What if widelands gets broken, because the c++11 implementation was changed?

----
My system:
Ubuntu 12.04
g++ 4.6.3

>Are there some specific feature you want to use? What do you think they
>will improve?
My sanity, mainly. I made a list of the features that I particularly
enjoy in the new standard and which gets rid of a lot of boilerplate. If
you are interested, you can have a look at my post at [1]

>Also I think the hint on this list is important that c++11 is still
>experimental. What if widelands gets broken, because the c++11
>implementation was changed?
The standard is through. The semantics must not change anymore. Of
course, compilers have known to be buggy from time to time, but I
consider it very unlikely that the new features will break something.
Most of the really useful ones are just writing shortcuts.

Does someone know something about the state of Visual C++?

[1] http://www.sirver.net/blog/2011/08/18/some-fancy-new-features-of-c++11/

I hear that the new version of Viual Studio will support c++11, but did some research [1]: It seams that it supports some more features but is far away from 100%.

[1] http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

In my oppinion the "new" for loop style, initializer lists, static_assert will surely help everyone. Especially the for loop, whenever I am confronted with some kind of the different lists in widelands, I have to search for the correct iterator macro. The most time I use them, it is some kind of try and error...

With the auto variables I do not know if it does more good or bad. For sure it is tempting to write "for(auto x : queue)". It is so nicely short, and I am a lazy guy ;) But auto variables are a little unclear. What type is x? If queue was not defined near the loop, you have to find it anywhere upwards, or in some header file.
Writing "for(WareId x : queue)" is not much longer, but more precise. I think this will help everyone, who gets in touch with some code the first time, or when you meet you own code after some time.

IMHO If the new c++11 feature will be used in widelands, we should think about which feature should be used and control this with the codecheck utility. Or I will for sure be the first one, who use auto variables ;)

After I read the artikle linked in #3, the use of c++11 should be limited to some specific features, as for example initializer list are not supported by VC.

What do you think about using a subset of the c++11 features?

Oh, people are able to write perfectly unreadable code as is already :).
What I mean is this: every feature of a programming language can be used
for good and for bad purposes. It is the programmers responsibility to
choose a good way. I feel the same about auto. It can increase
readability and portability and it can decrease it.

I feel bad to limit the features of c++ artificially just because we do
not trust our developers. A company might do this, but we are not in the
position. I'd say, go for all and see what programmers make from it and
decide on a per-case basis.

As one of the package maintainers for openSUSE I recommend to only use major features when supported for more than 3 years or building gets really complicated.

For openSUSE widelands builds only with last two versions and the minimum compiler support ATM should be gcc 4.5. Debian e.g. usually has much harder requirements.

For packages the approach to use every new function in a library, compiler, build script, ... makes a lot of trouble and kills support for older systems very fast. Backporting lots of infrastructure to make building possible usually is not done.

This should not be done without real need.

See also:
https://build.opensuse.org/package/rawlog?arch=i586&package=widelands&project=games&repository=openSUSE_11.4

Your point is not really valid. We don't release build18 now. We will release it at some point in the future. Today debian is packaging build17 using gcc-4.6. It's almost a save bet the next debian release will use at least gcc-4.7 and why should widelands use something else?
Do you remember Firefox 3, released June 30th, 2009? In the first place you don't run debian stable to get the latest software.

ubuntu builds widelands every night on 10 different machines and 8 will drop dead if we require gcc-4.7. but these machines are a snapshot of old software. You can pick a later snapshot and you will get newer software. Why would you even try to select one package and implant it to a system running only old stuff.

>
>ubuntu builds widelands every night on 10 different machines and 8 will
>drop dead if we require gcc-4.7.
I take from this that you also suggest not to jump to the C++11
bandwagon just yet, David?

That's probably a strong point against syntactic sugar. I mean how many foreach loops are you going to write this year. If someone would solve an interesting problem using c++11 features that would be something different.

Syntactic sugar is one thing (which helps to keep me sane :)). New
datastructures like tuple or hashmaps and lambda's is another. But boost
provides the datastructures and I can manage without the lambdas I
guess...

Setting to wontfix for now. You got me convinced everybody.

  status wontfix

Just a point related to Visual Studio 2012. Looks like free versions of VS2012 are just for Metro apps, so building widelands would require at least pro version. VS2010 express editions will stay online for C++ devs. Shevonar had a good link, that pointed out that new c++ feature support will be quite limited, and range based loops are not worth switching to new compiler. static_assert is already in VC10, so that's one safe feature.

Regarding VS2012, they changed their mind and will allow regular programs like in the past [1]. Though it is unclear to me whether the software produced would work on Windows XP [2]. And as long as a large portion of the world (and our players) are still on XP, excluding them would not be a wise idea.

Regarding comment #4 and #5, we will likely limit ourselves to a subset either way in order to match the common functionality implemented in the compilers we use. I have not checked, but I would assume gcc and clang (and vs for that matter) have focused on and implemented different parts, and we would need to know what they have in common to support all. After all, we just got clang builds working now.

In general, I understand that developers wish to use newer features and standards, though it would put a constraint on which compiler versions you can use in order to build Widelands. After all, we want Widelands available for everyone, regarding whether or not they have the latest version of a compiler. I think this discussion should likely be revisited at some point in the future when the recent releases of compilers have become more wide-spread.

[1] http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx
[2] http://en.wikipedia.org/wiki/Visual_studio#Visual_Studio_2012

More than one year later we did the leap and started with static_assert and unique_ptr in the code base. Let's see how much trouble this is d).

Released in build-18 rc1.