openmw.org

Hi all,

This is a quick reminder that GCC 6.1 has now been released. With this release the default is no longer C++98, and has been changed to C++14.

Now, I know we've had this discussion before*, but I feel that it's about time to discuss it again. Last time we looked at this the main issue was a significantly longer compile time with a specific, but common, version of GCC. I think at this point, that's not as large of an issue. Especially, after it becomes the default.

Why should we make this change? Well, C++14 will allow us to write simpler and safer C++ code. I'll admit that I'm not the best coder, but watching Bjarne Stroustrup's talks about code safety and how to propperly use the language is an eye opener. Unfortunately, several safety mechanisms are only available in the C++11 and 14 versions of the language.

What are everyone else's thoughts? Do you still feel the compile time makes it not worth it? Do you think we should explicitly specify C++98 even with the new compiler? Is there any one 'killer feature' you can't wait to use? Am I being too technical?

Please let me know!

*Might have been about C++11, but I couldn't find it with a quick search.

Have a link to these talks?

I'm in full support of moving to C++11, with some optional C++14 features when available, and dropping Boost. Anyone who has a habit of compiling C++ code is going to have to deal with C++11 at some point because more and more things are using it, and they do have options to fix it if they happen to have the specific compiler version that has performance problems (either upgrade GCC, or switch to Clang).

I really like this one: https://www.youtube.com/watch?v=1OEu9C51K2A

In it, he talks about ways to do things like eliminating resource leaks and dangling pointers without sacrificing performance.

I really like his "Within C++ is a smaller, simpler, safer language struggling to get out."

EmperorArthur wrote:I really like his "Within C++ is a smaller, simpler, safer language struggling to get out."

You mean C?

I wouldn't really call C "safe", especially when dealing with abstract interfaces and dynamic memory management, and it can get pretty complicated to deal with template-like stuff where you want the same basic function but with compile-time variations for types and values.

JesseMeyer wrote:

EmperorArthur wrote:I really like his "Within C++ is a smaller, simpler, safer language struggling to get out."

You mean C?

I hope you were kidding. But just in case... Of course not, this bullshit is making worse C++ code everywhere. Please don't spread it.

In the case it was really a joke. Then yes. it's funny

It's a joke within a joke. "Within C is a smaller, simpler, safer language struggling to get out." is also true!

Chris wrote:I wouldn't really call C "safe",

C code safety is a measure of how competent the programmer is. Which is the most important metric by far, as opposed to how the safeguards of the language were designed. Now if you're talking about the common case full stack web developer who doesn't know computer engineering, then yeah, they're going to sink the ship in the harbor. But this is a game engine forum where throughput and CS fundamentals play a central role in smooth sailing. A safe C programmer can write safe C++ code, but the converse is not true (necessarily).

My joke is that our languages in general are unnecessarily complicated.

Back to the topic, I thought C++14 was mainly a bug fixing standard over the C++11.

What features are you thinking?

C++11 is the big jump, but 14 makes it easier by adding a few things that were missing. For instance C++11 has 'std::make_shared' for 'std::shared_ptr' but C++14 adds 'std::make_unique' to 11's 'std::unique_ptr'.

While I have faith in everyone's abilities I know I sometimes make mistakes, so std::unique_ptr would be super nice. As an example, the NIF parsing code creates a bunch of node objects that are owned by the container. std::unique_ptr makes that explicit, and means we don't have to worry about deleting the objects, so it's guaranteed no memory leaks. Not that there are any in there, but It lets us remove code and more clearly show ownership with almost no overhead.