Subject: Re: [boost] painless currying
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-03 16:06:43
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
>> 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
> 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
the preprocessor may still parse the #elif expression, but it won't be
evaluated. If you want to avoid it being parsed, do
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk