Page 3 of 3

Re: C++11 Adoption stance

Posted: Sat Oct 14, 2017 7:07 pm
by paroj
qwertzui11 wrote:why not c++14?
which in my opinion is a "fixed c++11". eg. std::make_unique, improved and releaxed lambdas, releaxed constexpr and more
Ogre is used in lots of legacy codebases where C++14 is not available. e.g. with gcc 4.8.

Re: C++11 Adoption stance

Posted: Sat Oct 14, 2017 7:30 pm
by qwertzui11
paroj wrote:Ogre is used in lots of legacy codebases where C++14 is not available. e.g. with gcc 4.8.
makes sense. thx

Re: C++11 Adoption stance

Posted: Fri Aug 03, 2018 10:55 am
by al2950
paroj wrote:
Sat Oct 14, 2017 3:26 pm
Ogre 1.x will switch to C++11 with 1.11, see http://www.ogre3d.org/2017/09/02/ogre-1 ... erm-report
Its now 2018, any more thoughts on this for Ogre 2.x!? Windows compilers have come a long way, although admittedly I am not sure about compile times, everything is slow on my machine :lol: . I agree with a lot of the 'against' arguments here, but that are plenty of useful nugets in C++11.

Re: C++11 Adoption stance

Posted: Fri Aug 03, 2018 6:47 pm
by dark_sylinc
And MS has yet to produce a fast-building IDE & compiler!

Unfortunately, more evidence was brought to light. It would seem that Ogre compiles significantly slower even on Linux when compiled with C++11. Apparently the extra declarations in headers are to blame. A beer for whoever keeps saying "pay for what you use in C++".

It's sad because there are C++11 features I do would like to use: Override and final keywords are great (*), std::to_string is shorter than our StringConverter::toString, defaulted functions, forward declaring enums, static asserts, nullptr, and rvalue references.

(*) Though it's hard to start incrementally adopting it, because if you use it once, then clang/gcc will warn for every virtual function that is not using it. But still override & final probably get me more excited than most of the other features combined.

Some of this functionality has been floating on my mind though: Override & final can be implemented via Macros, i.e. OGRE_OVERRIDE (I think I prefer ogre_override, despite going against our guidelines, the all caps on every virtual function is too distracting) defines to nothing on C++03, but defines to override on C++11. Something similar can be done about nullptr, though I think defining "nullptr" in a header may be too bold. ogre_nullptr or OGRE_NULLPTR sounds a little silly, as it seems to be too verbose for very small gains.

Static asserts are also addressable in this way.

Other features like defaulted functions and rvalue references simply don't seem to have its workarounds into C++03.

But I haven't found the time to get deep into it.

Re: C++11 Adoption stance

Posted: Sun Aug 05, 2018 4:12 pm
by paroj
dark_sylinc wrote:
Fri Aug 03, 2018 6:47 pm
And MS has yet to produce a fast-building IDE & compiler!

Unfortunately, more evidence was brought to light. It would seem that Ogre compiles significantly slower even on Linux when compiled with C++11. Apparently the extra declarations in headers are to blame. A beer for whoever keeps saying "pay for what you use in C++".
this should be alleviated by precompiled headers or (urgh!) unity build.
dark_sylinc wrote:
Fri Aug 03, 2018 6:47 pm
std::to_string is shorter than our StringConverter::toString,
also it is 4x faster.

Re: C++11 Adoption stance

Posted: Sun Aug 05, 2018 4:57 pm
by dark_sylinc
paroj wrote:
Sun Aug 05, 2018 4:12 pm
this should be alleviated by precompiled headers or (urgh!) unity build.
Unity builds do compile faster which is good for users, but it is a PITA every time a single file is modified. Iteration times are the problem, and Unity builds do not solve iteration times.

Precompiled headers do not seem to significantly improve the situation. I suspect the problem may be that too many headers are being included. It is worth exploring if there are benefits if we only include the standard library there.
paroj wrote:
Sun Aug 05, 2018 4:12 pm
dark_sylinc wrote:
Fri Aug 03, 2018 6:47 pm
std::to_string is shorter than our StringConverter::toString,
also it is 4x faster.
I am not surprised :lol: StringConverter::toString implementation is an abomination.