Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-09-04 09:28:27

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.