C++11 Adoption stance

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: C++11 Adoption stance

Post 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.
qwertzui11
Halfling
Posts: 80
Joined: Wed May 14, 2008 10:44 am
Location: EU
x 22
Contact:

Re: C++11 Adoption stance

Post 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
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: C++11 Adoption stance

Post 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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: C++11 Adoption stance

Post 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.
paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: C++11 Adoption stance

Post 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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: C++11 Adoption stance

Post 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.
Post Reply