Extensive usage of reserved identifiers

[Erellu]

Before you go any further, maybe you want to link to very old issue. It was marked as completed in 2017, but as of e535556dbd31955e9205f9282602047034171c0f the problems are still there.

Several macros (and identifiers in general) use reserved names. This is undefined behaviour.

According to the standard (Cpp17 here):

20.5.4.3 Reserved names [reserved.names]
1 The C++ standard library reserves the following kinds of names:
—(1.1) macros
—(1.2) global names
—(1.3) names with external linkage
2 If a program declares or defines a name in a context where it is reserved, other than as explicitly allowed by this Clause, its behavior is undefined.

5.10 Identifiers
[...]
—(3.1) Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
—(3.2) Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Header guards

Header guards used in (almost) each .h file in OGRE follow one of the following conventions:

• __OgrePrerequisites_H__
• __CompositorManager_H__
• _ResourceManager_H_

All fall into 5.10 (3.2).

Export macro

_OgreExport, _OgrePrivate and probably other macros I'm not aware of fall into the 5.10 (3.1).

There may be other similar issues in other files, I did not check everything.

[paroj]

unless there is an actual conflict, I dont really care about this

[Erellu]

@paroj Thanks for your answer. I'd feel rather uncomfortable to live with undefined behaviour in my code, but I understand there are things more interesting and more urgent to do in such projects. Anyway, thanks again!

[elfring]

💭 Would you become interested to use a development tool like “clang-tidy” for corresponding source code adjustments?