That still evaluates x twice, which can also be a source of bugs. I usually take one of two approaches: either decide that this is a weekend hack and using the macros whenever the expansion isn't obvious in my head is a sign of too much complexity, or use this GCC extension:

    #define is_space(x) ({ typeof(x) y = x; y == ' ' || y = '\n'; })

(Or in this case, turn it into an actual function and let the compiler figure out optimization.)

GCC extensions make my brain hurt :( Should just use C++ at that point:

    template<class T>
    bool is_space(const T & x) {
        return x == ‘ ‘ || x == ‘\n’;
    }

Even better if you make it:

    template<class T>
    constexpr bool is_space(const T & x) {
        return x == ' ' || x == '\n';
    }

Debuggable, type safe and same performance as straight C code.

Constexpr is not necessary. Only required if you want to ensure that a variable is initialized with a pre-computed value. The compiler will optimize in either case if it can, regardless of the constexpr attribute.

> Only required if you want to ensure that a variable is initialized with a pre-computed value

Yep.

And throw an `inline` in there just to be more likely to end up with something macro-like.

`constexpr` is implicitly `inline`: http://en.cppreference.com/w/cpp/language/inline

orthogonally, templates are also implicitly inline.

Then again, inline does not mean what most people think.

“inline” is more about linkage than about actual inlining. The compiler will in-line regardless of that attribute.

The function can be trivially implemented in C, since you don’t need a generic input argument type. No idea why OP chose macros in the first place.

I'd argue that is_space() should be isspace(), the standard from <ctypes.h>. Pretty sure it wouldn't make the semantics of the language worse, but it's one less wheel re-invented and makes the code a smidgen easier to read since there's one less concept to learn in it. Also one less thing to debug ...

Heh. Make that <ctype.h>, of course. D'oh. :)