| Summary: | Corrections for reserved identifier violations | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Markus Elfring <Markus.Elfring> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | aristsakas |
| Priority: | VLO | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Markus Elfring
2009-09-08 22:47:50 UTC
Hmm, actually reading https://bugs.kde.org/show_bug.cgi?id=185901 suggests that the standard talks about C++ identifiers. #define __FOO__H__ is however not a C++ identifier, its just a preprocessor define and only ever seen by the preprocessor. Also google doesn't help me finding any evidence that this applies to the preprocessor definitions/macro's as well as the C/C++ identifiers. Would you like to clarify with any members (from the C/C++ standard committee) or other software developers if the wording in the language specification for the reserved namespace distinguishes between preprocessor symbols and all the other identifiers? How much do you really need to care for names with leading underscores? http://groups.google.de/group/comp.std.c++/msg/b7bf54575fbb8c1bv Is a preprocessor symbol like "__cplusplus" also a C++ identifier? Would you like to look at the table 98.1 in the book "The New C Standard: An Economic and Cultural Commentary" by Derek M. Jones if more name clashes can occur? http://www.knosof.co.uk/cbook/ Thanks but that table doesn't clarify this either. It only contains listing of macro's starting with "E" or "SIG" which seem to be reserved. However it doesn't say anything about macro's starting with "_" or "__", only about such identifiers. For now I'm closing this as needsinfo until someone can provide clear definitive answer to the question wether macro/defines starting with "_" and/or "__" are reserved. From which software experts will you expect and accept a definitive answer? (In reply to comment #6) > From which software experts will you expect and accept a definitive answer? The person doesn't play a role, the point is that none of the texts I've found so far is absolutely clear on whether the rule applies also to macro names and defines. I don't consider either to be part of the C or C++ language as they're processed by the respective language-compiler, but by a preprocessor. I haven't been able to find a standard on this preprocessor, so whether or not such rules exist for the preprocessor seems to be dependent on the actual preprocessor being used. Not to mention that I've already spent far too much time on such a minor issue. (In reply to comment #7) > The person doesn't play a role, the point is that none of the texts I've found > so far is absolutely clear on whether the rule applies also to macro names and > defines. I don't consider either to be part of the C or C++ language as they're > processed by the respective language-compiler, but by a preprocessor. Does the section "Scopes of identifiers" make it clear? http://c0x.coding-guidelines.com/6.2.1.html For c0x (which actually doesn't exist anymore and rather is c1x now) yes. But what about c99 and the current C++ standard? After KDevelop doesn't yet support c0x. anyway, I'm not going to argue anymore. But don't expect anybody to work on this. |