Orxonox goes C++11

[x3n]

We're about to move to C++11!

Everyone who's interested in the topic can have a look at branch cpp11_v2: http://www.orxonox.net/browser/code/branches/cpp11_v2
You're welcome to test the branch, see if it compiles and works for you, and to add your favorite C++11 features to Orxonox!

To use all features of C++11 you will probably need at least the following compiler versions to build Orxonox:
- GCC: 4.8
- MSVC: 2014
Of course this depends on the features of C++11 that we will actually use in the end.
Anyway, the trunk of Orxonox works with said compiler versions (including precompiled dependencies for windows).

If you're currently not in the mood to introduce new C++11 features yourself in the code, you can still use this thread to add your suggestions.

Here's the current list of suggestions ([x] means done, updated 31. dec 2015):
[x] Use constexpr for Math.h functions (and other constants) [done: 1. nov 2015 by landauf]
[x] Add move-constructor for StrongPtr and SharedPtr [done: 1. nov 2015 by landauf] (are there other places where we could use this?)
[x] ObjectList should support range-based-for-loops [done: 31. oct 2015 by bknecht & landauf]
[x] Replace the usage of ObjectListIterator with range-based-for-loops [done: 5. dec 2015 by landauf]
[x] Replace iteration over standard containers with range-based-for-loops [done: 21. nov 2015 by muemart]
[x] Introduce lambda functions for timers, callbacks and generally for all kinds of Functors [done: 23. dez 2015 by muemart]
[x] Use constructor delegation where it makes sense [done: 29. dec 2015 by landauf] (are there other places where we could use this?)
[x] Use default and delete for constructors (specially for non-copyable classes) [done: 29. dec 2015 by landauf]
[x] Use 'override' for overridden virtual functions [done: 19. nov 2015 by muemart]
[x] Replace NULL (or 0) by nullptr [done: 6. nov 2015 by landauf]
[x] Use enum class (instead of the legacy enums) [done: 30. dec 2015 by landauf]
[x] Replace "> >" by ">>" [done: 7. nov 2015 by landauf]
[x] Make conversion-to-bool-operator explicit in all our smart-pointers [done: 7. nov 2015 by landauf]
[x] Use variadic templates for functor [done: 27. nov by muemart]
[x] Use static_assert instead of the boost macro STATIC_ASSERT [done: 7. nov 2015 by landauf] (are there other places where we could use this?)
[x] IdentifierManager should store Identifiers by type_index [done: 28. dec 2015 by landauf]
[x] Replace std::auto_ptr with std::unique_ptr [done: 7. nov 2015 by landauf]
[x] Use new features from the standard library instead of boost (e.g. shared_ptr, bind, etc.) [done: 8. nov 2015 by landauf]
[x] Use new random number generator instead of rand() [done: 17. nov 2015 by muemart]
[x] Replace SharedPtr with std::shared_ptr [done: 22. nov 2015 by landauf]
[x] Use the chrono library to add milliseconds to the timestamp in logfiles [done: 29. dec 2015 by landauf]

[-] ?? Maybe we can use the alignment specifiers (alignas/alignof) in WorldEntity to replace the new/delete-overloads? -> Update (31. dec 2015 by landauf): No this cannot replace the new/delete-overloads. However, alignas(16) could be used to replace bullet's ATTRIBUTE_ALIGNED16 (but that's none of our business).

[muemart]

Maybe some things from the standard library can be used too. unique/shared_ptr, unordered_map/set, etc. Functor and executor might be able to benefit from std::function.
I personally never used it, but clang-modernize was made for this purpose, right? Probably useful for the tedious stuff (adding override...)

[x3n]

clang-modernize

Oh wow, never heard of that. That could be really helpful. But I'm not sure if Orxonox already compiles with clang. Last time I tried to use clang, I got tons of warnings on the first few files...

Anyway, making Orxonox work with clang could be an interesting side project. Any volunteers?

Btw, in the meantime I introduced 'nullptr' (and updated the list in the first post).

[muemart]

I think clang is supposed to be a drop-in replacement for gcc, so it should work. I tried it yesterday with msys2 on windows, but couldn't compile with neither gcc nor clang. I'll leave it to people who already have a working non-MSVC setup

[x3n]

Yes it supports the same compiler arguments like gcc, but that doesn't neccessarily mean it accepts the same code and issues the same warnings

[muemart]

Well, MSVC is the notorious one for its bad C++ support, so clang is probably not very problematic.

Anyway, I tried to use variadic templates for the functor, and while a lot of lines could be removed, I feel like the code actually became a bit more complex, but is still limited to five parameters. It seems to compile and work fine, but I had to use a C++14 library function to make it really work (make_index_sequence). I attached a patch if someone is interested.

[x3n]

Fascinating, thanks! I'll have a look at it. Ideally we could work around the limitation of 5 parameters and C++14.
For make_index_sequence I think we need at least GCC 4.9 (and MSVC14).

[muemart]

The 5 parameters come from the virtual function with 5 multitypes in the base class. I can't think of a nice way to remove that limit and provide the same functionality, but I don't often work with templates so maybe someone else has an idea. The index sequence can be backported to C++11 I think, there are some things floating around on stackoverflow.

[x3n]

During the past two months we worked through the checklist from the first post of this thread. There was some tedious work (using 'nullptr', adding 'override', etc.) and some tricky work (like variadic templates, type traits, etc.). Thanks a lot to muemart for doing many of those tasks!

The branch will be merged back to trunk soon. Until then, you still have the chance to test the branch and check if it works on your particular system. After the merge you're of course encouraged to use C++11 features in your code (and to refactor existing code to use these features).

Important: From now on you need at least GCC 4.8 and/or MSVC 2014 (~Visual Studio 2015). Older compilers are not supported anymore.

[muemart]

I just had to find out that the std::string forward declaration in OrxonoxConfig.h is not correct for newer libstdc++ versions, because the declaration is actually inside an inline namespace. We could fix this by using some internal preprocessor stuff from the library which is a bit hacky, or just outright remove the forward declaration because there's no guarantee that it will work in the future. Opinions?

[x3n]

I think it's better to remove the forward declaration instead of making it even more hacky. Instead you can include <string> where it makes sense (e.g. UtilPrereqs.h and CorePrereqs.h... or maybe already in OrxonoxConfig.h?)

[x3n]

I merged the branch back to trunk. Orxonox is now officially a C++11 project

[flozi]

Good job, thanks a lot for your effort!

I got this warning while compiling on gcc 5.2.1 (ubuntu 15.10)

Code: Select all

In file included from /home/flo/orxonox/trunk/src/libraries/core/BaseObject.h:51:0,
                 from /home/flo/orxonox/trunk/src/libraries/tools/ResourceCollection.h:36,
                 from /home/flo/orxonox/trunk/src/libraries/tools/ResourceCollection.cc:29,
                 from /home/flo/orxonox/trunk/build/src/libraries/tools/ResourceBuildUnit.cc:1:
/home/flo/orxonox/trunk/src/libraries/core/class/OrxonoxClass.h:53:23: warning: defaulted move assignment for ‘orxonox::OrxonoxClass’ calls a non-trivial move assignment operator for virtual base ‘orxonox::Configurable’ [-Wvirtual-move-assign]
     class _CoreExport OrxonoxClass : virtual public Configurable, virtual public Destroyable

It's not a real issue, but I don't like warnings (orxonox didn't have any before...) and I have absolutely no clue what this warning is about. I tried googling of course, but I'd have to take a massive detour into deep c++11/14 land to just get an idea of what it's about, so I thought I just leave it to the experts here ;-P
Also, I wasn't sure if you would see the warning using visual studio.

Apart from that it compiled fine and also works as it normally does.

[x3n]

Thanks. I got that warning too with gcc 4.8.1, but I thought that it is bogus and gcc fixed it in 4.8.2.
But now that you get this warning also with a recent version of gcc I should probably have a closer look at it.

[x3n]

Ok here's a small snippet that reproduces the warning with my compiler (gcc 4.8.1):

Code: Select all

class A { };
class B : virtual public A { };
class C : virtual public B { };
class D : public C { D& operator=(const D&) = delete; };

And here's a snippet that fixes the warning (by adding a defaulted assignment operator to C):

Code: Select all

class A { };
class B : virtual public A { };
class C : virtual public B { C& operator=(const C&) = default; };
class D : public C { D& operator=(const D&) = delete; };

The first snippet results in said warning, the second snipped compiles without warnings.
You can add the snippet to any source file in orxonox and try if you can reproduce this behavior with gcc 5.2.1

In my opinion the warning is bogus.
This is also the opinion in this bug-report (gcc): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319
According to this report the issue was fixed in gcc 4.8.2, but maybe it re-appeared? Or maybe our case is somewhat different?

For the moment I attempted to fix the warning by adding a defaulted assignment operator to OrxonoxClass (http://www.orxonox.net/changeset/11082). But it would be interesting to see if you can reproduce my observations with your compiler.