C++11 Adoption stance
Posted: Mon Mar 03, 2014 2:32 pm
This question keeps popping up from time to time, so we're going to address it here and make it sticky:
What's the stance on C++11 in Ogre?
It's not gonna happen for a long time. We won't adapt a language feature just because of fashion. There are multiple reasons for doing this:
For example, VS 2012's high_resolution_clock isn't high resolution. Not something you would really expect. Some atomic's usage are also several times slower than they should be.
This problem affects all compilers. It would take at least 5 years until the std lib has matured and proven to work as one would expect. Nowadays developers suggest that std::vector<T> should deliver the same performance as a raw pointer. But this wasn't true during the first years. vector<T> used to be a huge bloat. This is normal software development cycle.
In some game companies, you can literally get fired for adding Boost as a dependency to the game engine. It bloats the executable size (and thus runtime performance), increases memory footprint, and greatly increases the compilation time.
Boost is useful for simplifying your life in regular programs, but it has no place in low latency, high performance graphics engines.
Instead we're using our own cross-platform primitives where we can focus on quality and performance while maintaining dependencies and compilation time to a minimum, without the pressure of supporting every use case. Such examples are the classes LightweightMutex, Barrier, ThreadHandle and the functions Threads::CreateThread and Threads::WaitForThreads. A bonus benefit is that debuggers produce a much cleaner call stack when debugging multiple threads. In other words, it's also cleaner.
Auto is useful inside templates, since the variable type may not be known until compilation or specialization, or when the syntax inside the template gets too complex. However using auto outside templates (or everywhere!) is an abuse.
It can even introduce subtle bugs: e.g.
The first one may be intended to be a float, but the 'f' was missing.
The third one may be supposed to be an integer, but the extra '.' made it a double. Easy to miss.
The fourth one is the worst kind. Signed integer overflow is undefined behavior. Unsigned integer overflow is well defined (wraps around). This can have unforeseen consequences:
Most likely we will end up banning the usage of auto keyword outside templates or specific cases. We would have to also analyze what happens with other C++11 additions like lambdas. The point is, we can't just rush and let contributions using C++11 syntax go ahead. We have to sit down and think about it.
When all these problems get addressed, we will reevaluate adoption of C++11. But for the time being, it's not gonna happen.
The OGRE team.
What's the stance on C++11 in Ogre?
It's not gonna happen for a long time. We won't adapt a language feature just because of fashion. There are multiple reasons for doing this:
- Cross platform compiler
- On Windows, compilation performance sucks
- The standard library hasn't matured yet
For example, VS 2012's high_resolution_clock isn't high resolution. Not something you would really expect. Some atomic's usage are also several times slower than they should be.
This problem affects all compilers. It would take at least 5 years until the std lib has matured and proven to work as one would expect. Nowadays developers suggest that std::vector<T> should deliver the same performance as a raw pointer. But this wasn't true during the first years. vector<T> used to be a huge bloat. This is normal software development cycle.
- Boost is not a replacement for C++11
In some game companies, you can literally get fired for adding Boost as a dependency to the game engine. It bloats the executable size (and thus runtime performance), increases memory footprint, and greatly increases the compilation time.
Boost is useful for simplifying your life in regular programs, but it has no place in low latency, high performance graphics engines.
Instead we're using our own cross-platform primitives where we can focus on quality and performance while maintaining dependencies and compilation time to a minimum, without the pressure of supporting every use case. Such examples are the classes LightweightMutex, Barrier, ThreadHandle and the functions Threads::CreateThread and Threads::WaitForThreads. A bonus benefit is that debuggers produce a much cleaner call stack when debugging multiple threads. In other words, it's also cleaner.
- Adoption requires modifying coding standards
Auto is useful inside templates, since the variable type may not be known until compilation or specialization, or when the syntax inside the template gets too complex. However using auto outside templates (or everywhere!) is an abuse.
It can even introduce subtle bugs: e.g.
Code: Select all
auto x = 7.0; //This is a double
auto x = 7.0f; //This is a float
auto x = 7.; //This is a double!!!
auto x = 7; //Is this an int or a uint?
The third one may be supposed to be an integer, but the extra '.' made it a double. Easy to miss.
The fourth one is the worst kind. Signed integer overflow is undefined behavior. Unsigned integer overflow is well defined (wraps around). This can have unforeseen consequences:
Code: Select all
auto x = myInteger; //int myInteger = 262144; causes undefined behavior as result should be 68719476736, but doesn't fit in 32-bit
if( x * x < x )
{
//The compiler may optimize this away. Which wouldn't happen if 'x' were unsigned.
}
When all these problems get addressed, we will reevaluate adoption of C++11. But for the time being, it's not gonna happen.
The OGRE team.