Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-09-03 23:26:57

On 9/3/2011 4:06 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Sat, Sep 3, 2011 at 8:15 AM, Edward Diener<eldiener_at_[hidden]>wrote:
>
>> On 9/1/2011 9:40 PM, Paul Mensonides wrote:
>>
>>> On Thu, 01 Sep 2011 18:23:16 -0400, Edward Diener wrote:
>>>
>>>   The remark refers in the resolution above refers to "my reading of the
>>>> standard" but does not say which standard is being referred to. Is this
>>>> part of C99 or C++11 ? I have asked about this on the C++ standard NG
>>>> and am awaiting an answer.
>>>>
>>>> I am surprised by the evaluation of "#elif constant expression" when the
>>>> corrwesponding #if statament is true because it means that #if - #elif
>>>> is not equivalent to #if - #else - #if in this particular case, and I am
>>>> sure many C++ programmers would have expected that the two were indeed
>>>> equivalent.
>>>>
>>>
>>> It doesn't "evaluate" it; it just parses it.  Even in normal code and, in
>>> most cases, even with dynamically-typed code, the compiler or interpreter
>>> still has to parse the else-if expressions.
>>>
>>
>> So if I have:
>>
>> #if 1
>> #else
>> nonC++gobbledygook
>> #endif
>>
>> The compiler still parses nonC++gobbledygook and issues an error if it is
>> invalid C++ code ?
>>
>
> No, I believe here Paul is referring to a "regular" if/else if expressions,
> not preprocessor directives.
>
>    Neither C99 or C++98 (or C+
>>> +11) are particularly clear on this.  To me that means that the solution
>>> is on the code side rather than requiring a compiler to allow semi-
>>> unspecified behavior in the short term and to alter the standard if it is
>>> important enough in the long term.
>>>
>>
>> I admit that I have always thought that an #if - #else - #endif path which
>> is not taken can be anything and does not have to be valid C++. You seem to
>> be saying otherwise.
>>
>
> I think Paul is saying that for
>
> #if 1
> #elif nonC++gobbledygook
> #endif
>
> 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.