Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reserved identifier violation #3

Closed
elfring opened this issue Mar 27, 2015 · 4 comments
Closed

reserved identifier violation #3

elfring opened this issue Mar 27, 2015 · 4 comments

Comments

@elfring
Copy link

elfring commented Mar 27, 2015

I would like to point out that identifiers like "__QCONF_CMD_H__" and "__QCONF_COMMON_H__" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

@haveTryTwo
Copy link
Contributor

Thanks for your advise!
The "Noncompliant Code Example" : #define _MY_HEADER_H_ , and the reason why it's noncompliant is "The name may clash with reserved names defined by the implementation of the C++ standard template library in its headers or with reserved names implicitly predefined by the compiler even when no C++ standard library header is included"; and the macro defined in C++ standard template library may be like #ifndef _GLIBCXX_ISTREAM that begins with an underscore, so avoiding using leading or trailing underscores in the name of the header guard may be compliant solution.
But this may be not only one compliant solution! The 'Google C++ Style Guide' advise the symbol name should be : #define PROJECT_PATH_FILE_H_ . I think if it can achieve the purpose that not clash with reserved names defined by the C++ standard template, the macro that begins and ends with double underscore may be also ok.
Do you think so?

@elfring
Copy link
Author

elfring commented Mar 28, 2015

It is popular to use a suffix like "_H" for include guards. - There are better ways to make your identifiers reasonably unique.

Would you like to avoid that your software depends on undefined behaviour?

@haveTryTwo
Copy link
Contributor

To make our identifiers unique, we'll take your advice, thanks again!

@elfring
Copy link
Author

elfring commented Mar 31, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants