Correct header inclusion guards to comply with C++ standard

[CABAListic]

I find the lack of proper module support C/C++'s greatest weakness, so yeah, the whole header stuff is messy, pragma once or not
I think the bottom line here would be "if it isn't broken, don't fix it".

But I agree that pragma once is an improvement over header guards. I might start using that for my personal projects.

[masterfalcon]

My only concern with using pragma once in Ogre is portability. Yes, it's supported by all major compilers. But we can't guarantee that it will be everywhere that someone wishes to port Ogre to.

Yeah, it's a few extra lines per header, so what? We're talking about a difference of 2 lines of code.

Code: Select all

#ifndef _OGRE_HEADER_
#define _OGRE_HEADER_
#endif

vs

Code: Select all

#pragma once

I agree with CABAListic, it's not broken, let's not fix it.

But...if there are some significant compilation speed improvements, we can talk. But we'll need benchmarks on a few compilers to back that up.

[Kojack]

http://tinodidriksen.com/2011/08/31/cpp-include-speed/
Benchmark with vc2010, gcc 4.6.1 and clang 2.9, including 10000 headers three times each.

vc2010 is 1.5 seconds slower to do 30000 includes with include guards than pragma once.
gcc is 1.7 seconds slower to do 30000 includes with pragma once than include guards.
clang is 0.036 seconds slower to do 30000 includes with include guards than pragma once.

[Wolfmanfx]

Seems we should keep #ifdef because we have more gcc/clang backends than msvc and honestly 1.5sec is not a huge time loss on msvc(and that with 30k headers) and in our case its not measurable i guess.

[Stymgade]

Apologies for the bump, but is there still a desire to update the inclusion guards to comply with the standard?

In regards to conflicts with existing definitions for 'common' words/phrases, I've been using something similar to this format:

Code: Select all

#include "PROJECT_FILENAME_H_INCLUDED"

*_H_INCLUDED is rare to match any existing definitions (but granted, not totally infeasible) - and Ogre has been designed well enough not to use the same filenames in different locations, so it should work here.

I'm a stickler for standards compliance (and no warnings!); if there's still interest in this, I'd be willing to painstakingly update all the guards

[scrawl]

See the bug report, it's scheduled for 2.0 as to not cause too many merge conflicts: https://ogre3d.atlassian.net/browse/OGRE-316