Proposal: upgrade to C++11

[Lyberta]

Hi.

First of all, some info for those who are not familiar with C++. C++ is defined by ISO standard ISO/IEC 14882. Revisions of the standard are marked by the year they are published. So far, there has been 3 revisions: ISO/IEC 14882:1998, ISO/IEC 14882:2003 and ISO/IEC 14882:2011. Informally they are called C++98, C++03 and C++11. Currently, fourth revision is in being worked on having the status of Committee Draft, expected to become C++14.

Now, I've looked at the source code of Red Eclipse and was a bit shocked. It looks like it was developed in pre-C++98 era. It doesn't look like C++ to me, rather some weird dialect of C. So I'm proposing to make the code up with times or at least allow C++11 in the new contributions.

Why? Here are some notable features of C++11:

• Move semantics - allows you to avoid unnecessary copies and make old code faster without change to it.
• Smart pointers - forget about manually managing memory and worrying about memory leaks. You also get exception safety.
• Standard multithreading - again, forget about OS-specific code to handle concurrency. You now have a standard way to express multithreaded code.
• Explicit Unicode support - you no longer have to live in implementation defined execution character set but instead can be sure that your code is in fact Unicode.
• Lambda expressions - you can now express algorithms as they are meant to be.
• Much more.

The industry is rapidly moving towards C++11:

• The C++ Programming Language, 4th edition - the book by Bjarne Stroustrup, the creator of C++, uses C++11 freely.
• Guru of The Week - the legendary series by Herb Sutter, the chairman of standardization committee, are being updated to C++11/14.
• Scott Meyers is working on a new C++11/14 book.
• Many real world projects are already using C++11, just watch some videos from C++Now or other C++ conferences.

The compiler support:

• GCC 4.8.1 has complete support in the compiler. libstdc++ is still lacking some components.
• Clang 3.3 with libc++ has complete support in both compiler and standard library.
• Visual Studio 2013 Preview supports roughly 60% of the features. (But who cares about Visual Studio, right?)

Lastly, I really want to contribute code to Red Eclipse, but I've spent years learning C++11, all my code is written in C++11 and it would be very uncomfortable to code anything without C++11.

I've asked for this in IRC and got a very strong opposition from graphitemaster, through he is not part of development team and seemed to be the only one opposing. When I've asked him about coding guidelines, I got this. It bans half of the features of even C++98 and I'm not going to contribute under these guidelines. If all else fails, I'm going to create a network-compatible fork on which I'll be testing my ideas.

If, however, this proposal will be accepted, expect (another) generous donation from me.

[arand]

Well. the coding style for cube2 and in extension Red Eclipse is (as far as I know) very much designed to be a lean version of C++ without all the latest bells and whistles, and I get the impression that most developers working with cube2/Red Eclipse share that opinion.

I think that getting RE/cube2 moving to C++11 (and using all the latest toys of it) is VERY unlikely.

Rewriting RE in C++11 with its modern toys might be an interesting exercise, but I doubt it would be more than an educational one, since it would be a very large project, and none of the original developers are likely to follow.

[Lyberta]

I'm not demanding RE to be completely rewritten outright. Right now I want C++11 be allowed in new contributions. That way I could slowly start rewriting it bit-by-bit and also contribute new features.

Again, there seems to be some cargo cult of not using some C++ features which were not widely supported in the 90s. The world has changed and C++ support is much better. Using C++ as it meant to be used leads to a cleaner and less error-prone code.

[ballist1c]

...strong opposition from graphitemaster, through he is not part of development team and seemed to be the only one opposing. When I've asked him about coding guidelines, I got this. It bans half of the features of even C++98 and I'm not going to contribute under these guidelines

the real, original list is actually this, sorry

[qreeves]

{l Code}: {l Select All Code}

Prologue:
In the beginning there was Cube, a game engine designed with content
creation being a simple concept for anyone to grasp. The code of this
engine was wrote in a relatively new to the scene language known as
C++. The standard library at the time not heavily adopted by many
compilers, and not really optimal, nor acceptable for production
quality code. This brought forth hand-roll'd alternatives to more
widely known and adopted containers that exist in the standard C++
library.

This main demise held true for a long time, and it still holds true
to this day for many modern compilers. C++ provides a flexible environment
to work in, it does not enforce a particular paradigm, style, nor standard.
It does allow you to use your own, and it has to for a variety of reasons.
It's not unacceptable for a project to need a specific style. Cube2 (the
successor of Cube holds true to this old style for these reasons and a
variety of other reasons pertaining to platform consistency, performance
and space considerations).

The following features are not to be used (or suggested / implemented):
    Exceptions                - throw, catch, try, etc
    RTTI                      - typeid, dynamic_cast, etc
    Standard library          - anything in std:: namespace
    Boost libraries           - just say no to drugs kids
    Excessive OOPisms         - remember, OOP is POO spelt backwards (but OOP is fine where it makes sense)
    Complex templates         - complex specializations or "hacks" like SFINAE, don't use them.
    Safe pointers             - don't implement this, managing memory is not HARD
    C++ named casts           - static_cast, const_cast, reinterpret_cast, just use C style casts
    Multiple inheritance      - inheriting from multiple pure instances is OK, as long as at most ONE base class.
    Deep inheritance          - there is no need to inherit deeply to save bits of coding here in there, inherit to "REUSE" not "ABUSE"
    Unnecessary headers       - don't include things if you don't need them
    Compiler extensions       - don't use without consulting other developers
    Anything in C++11         - vendors don't fully support it, and it looks like they never will.
    Iterators                 - grep the source for `enumerate` to see how it should be done.
    Member function pointers  - you're over-engineering, STOP!
    Access Specifiers         - public, private, protected, just use struct instead of class and keep everything public (it's implicit with struct)
    Overloading operators     - only when it makes sense, stop trying to be clever.

We do things this way semi-on-purpose, so I doubt that is ever going to change. I think RE does violate some of these rules, but only in fringe cases which don't matter. As with any (open source or group) project, you will be expected to learn and adhere to the programming practices already in place (unless, of course, your area is completely isolated or mostly-compatible).

I'm not going to contribute under these guidelines. If all else fails, I'm going to create a network-compatible fork on which I'll be testing my ideas.

All I can say is this:

Please don't be offended if I don't include your content in the game, it probably just means that it is not suitable or fitting with the "grand vision", or simply that you need some more experience before you're capable of producing the kind of content that we require. It really isn't helpful when someone cracks the shits and declares they will fork and make their own game, building a community is different to building a game, and both are required to be successful.

More often than not, my job includes more than just making decisions and writing blobs of code. My job here is everything you could possibly require doing on a project of this scale. This includes encouraging you, and helping you better yourself. I'm not above taking someone who is willing to give it a try aside and helping them myself, but you need to understand that I stretch myself thin as it is. Treat me with the proper respect and be patient, and you will find yourself rewarded in kind.

[Lyberta]

Okay then, I see that some of my points were written a little too radical mainly because I love the game and was being overly enthusiastic about contributing. For now, I guess I'll keep whatever I come up with in terms of code in some separate place in the hopes of current guidelines being revised in the future.

[Ulukai]

Okay then, I see that some of my points were written a little too radical mainly because I love the game and was being overly enthusiastic about contributing. For now, I guess I'll keep whatever I come up with in terms of code in some separate place in the hopes of current guidelines being revised in the future.

That will most likely result in your work, which could be beneficial for the whole community, ending up in a forgotten folder on your disk at some point in time. Why not tell a bit more about your ideas and what you can bring to the game instead?
And if you love the game so much, adapting a little shouldn't be too hard. Remember that guidelines are there to facilitate contributing and most of the programming work of RE is voluntarily done by only two hands. Your proposal implies a major effort and it wouldn't improve the game that much, except for making a possibly better and cleaner codebase. Implementing new and fun stuff is time consuming enough already, maybe that should be the focus of development?

[Bobbo]

Your proposal implies a major effort and it wouldn't improve the game that much, except for making a possibly better and cleaner codebase. Implementing new and fun stuff is time consuming enough already, maybe that should be the focus of development?

This comment is very double edged in my eyes. If, let's suppose, Quin wanted to add a new weapon, he'd have to change all of the hard coded functions for that new weapon. game/weapdef.h is a file of just #define'd functions to set what seems to be weapon defaults, and there seem to be one of those functions for every variable, with each weapon having 4 listings (pri, priflak, sec and secflak), so that's like.... literally hundreds of lines of code to change to add a single new weapon to RE. Where as if things we OO (or even had structures) a new weapon would just be a variation of a base weapon, which would take considerably less time to do.

I wouldn't be surprised if the same was true for new game modes or AI types.

So while refactoring to a better standard would big a giant project and take lots of time, the end result is quicker and cleaner code for the future, and thus implementing new stuff, and releases are much quicker. I don't really know much about the development team except it's lead by Quin and a lot of resources are player generated, but it gives me the felling that if we lost Quin for some reason the project would be pretty dead until someone has the willpower to live and breath the code for a few months to actually understand the current structure. Right now it just seems the data is initialized and used in random places with no real structure and nothing to help anyone who actually wants to contribute.

[qreeves]

Where as if things we OO (or even had structures) a new weapon would just be a variation of a base weapon, which would take considerably less time to do.

I dunno what mushrooms you've been eating, but what language I choose to use for the code has nothing to do with modularity. I could use straight C and write a modular environment.

So while refactoring to a better standard would big a giant project and take lots of time, the end result is quicker and cleaner code for the future, and thus implementing new stuff, and releases are much quicker. I don't really know much about the development team except it's lead by Quin and a lot of resources are player generated, but it gives me the felling that if we lost Quin for some reason the project would be pretty dead until someone has the willpower to live and breath the code for a few months to actually understand the current structure. Right now it just seems the data is initialized and used in random places with no real structure and nothing to help anyone who actually wants to contribute.

You need to understand that maintaining the Cube code standard is just as much for eihrul as it is for me. He maintains backports and new features beyond my ability, because he is much better at low level programming than almost everyone in all the Cube communities combined. He does this for RE because he cares about the codebase and its integrity, therefore it is best to keep the code in the format both he and I prefer.

As I keep saying, we're making a game, not an engine; I'll only ever do what I personally want to do - and redesigning the entire engine is far less appealing than writing the game itself. In the end, I accept code contributions very seldomly, and we tend to rewrite most patches ourselves: being unfamiliar with the code, most patches people submit are incorrectly done.

If I died, I think you'd have more problems than just the code to deal with, as I manage quite a lot of the project singlehandedly (in terms of overall team contribution). Anyone taking over my position would have a lot to learn, regardless, as there is an entire ecosystem to comprehend and there are only a handful of "Cube Engine Experts".

[Bobbo]

Where as if things we OO (or even had structures) a new weapon would just be a variation of a base weapon, which would take considerably less time to do.

I dunno what mushrooms you've been eating, but what language I choose to use for the code has nothing to do with modularity. I could use straight C and write a modular environment.

Who said anything about language? You could also use any number of languages supporting OOP.

You need to understand that maintaining the Cube code standard is just as much for eihrul as it is for me. He maintains backports and new features beyond my ability, because he is much better at low level programming than almost everyone in all the Cube communities combined. He does this for RE because he cares about the codebase and its integrity, therefore it is best to keep the code in the format both he and I prefer.

I understand that, but are you saying that the current guidelines (as linked above) are both your preferred ways to program? Or is this the way it is because of how Cube was originally written?

If I died, I think you'd have more problems than just the code to deal with, as I manage quite a lot of the project singlehandedly (in terms of overall team contribution). Anyone taking over my position would have a lot to learn, regardless, as there is an entire ecosystem to comprehend and there are only a handful of "Cube Engine Experts".

I know that, there's bills, PR, leadership stuff, server stuff etc. But an obscure system isn't going to help in such an event. Just seems a bit like a cook book with the instructions in the wrong order.


So is the overall answer to this thread:
No, because:

• Quin and eihrul decided on a format that's good for them.
• C++11 standard because it's not fully supported?
• ...

Also, the programming practise/guidelines list further up in this topic. I'm interested in the reason why all of these things are in there. Some are explained why not to use them, but most are just what they are or what to do instead.

[Lyberta]

To be honest, the game can be coded separately from the engine, but I think this particular community already decided (by 2 men) what's good for it.

[ballist1c]

If the community trusts, recognizes and openly acknowledges those 2 men as the leaders of their community, then there is nothing wrong with that. A spiteful undertone won't help win people over.

[Ulukai]

If the community trusts, recognizes and openly acknowledges those 2 men as the leaders of their community, then there is nothing wrong with that. A spiteful undertone won't help win people over.

+1

Why is it so hard for people to be happy with what they get?

[qreeves]

To be honest, the game can be coded separately from the engine, but I think this particular community already decided (by 2 men) what's good for it.

Yes, and now I decide that your attitude is not welcome here. It's funny, I was just discussing a more lenient consequence for your behavior until you pulled this stunt. Go make your own project and run it how you like. The end.

[charlie]

Okay then, I see that some of my points were written a little too radical mainly because I love the game and was being overly enthusiastic about contributing. For now, I guess I'll keep whatever I come up with in terms of code in some separate place in the hopes of current guidelines being revised in the future.

If you have radical ideas, you can always fork. That's the beauty of open source.