On 9/3/2011 11:54 PM, Paul Mensonides wrote:
On Sat, 03 Sep 2011 23:26:57 -0400, Edward Diener wrote:
On 9/3/2011 4:06 PM, Jeffrey Lee Hellrung, Jr. wrote:
the preprocessor may still parse the #elif expression, but it won't be evaluated. If you want to avoid it being parsed, do
#if 1 #else #if nonC++gobbledygook #endif #endif
I understand what you are saying but I still think it is a terrible C++ inconsistency that #elif is not the same as #else - #if. Then again maybe I see it that way because I was never aware of the "difference" but I would bet if you asked 100 very good C++ programmers the difference between them, 99 would almost immediately say that there is no difference, #elif is purely a shorthand for #else - #if.
For the record, I'm not saying that I think it is *good* that gcc is doing that. But, I don't think that the standard forbids it. Therefore, there are only two acceptable options: 1) use the "safe" method and, if worthwhile, 2) change the standard. I don't consider changing gcc and relying on unspecified behavior to be an option.
Since parsing the #elif expression or not, when it is not a valid path, can change the behavior of the translation unit ( possible compiler error or no compiler error), I would think the standard has to rule on this issue. I do not think it should say that the result is implementation defined.