[Boost-users] Boost Phoenix Arguments Passing & Storage (-- Proper Type?) & Application to RValues -- Possible?

Subject: [Boost-users] Boost Phoenix Arguments Passing & Storage (-- Proper Type?) & Application to RValues -- Possible?
From: Matt (matdzb_at_[hidden])
Date: 2012-02-14 16:43:30

Hi there!

I've got a question (two, in fact) regarding Arguments in Boost Phoenix.

Assuming
        using boost::phoenix::arg_names::arg1;
        using boost::phoenix::val;
        using boost::phoenix::ref;
        using boost::phoenix::cref;

Why does this compile (and works):
        int x = 1;
        int y = 2;	
        std::cout << (arg1 % 2 == 1)(x) << '\n';
        std::cout << (arg1 % 2 == 1)(y) << '\n';

while these fail to compile (with an extremely long diagnostic involving 
"boost::error_cant_deduce_type"):

        std::cout << (arg1 % 2 == 1)(1) << '\n';
        std::cout << (arg1 % 2 == 1)(2) << '\n';

        std::cout << (arg1 % 2 == 1)(val(1)) << '\n';
        std::cout << (arg1 % 2 == 1)(val(2)) << '\n';

        std::cout << (arg1 % 2 == 1)(cref(1)) << '\n';
        std::cout << (arg1 % 2 == 1)(cref(2)) << '\n';

I run into this was while attempting to store an Arg. into a variable, 
i.e.,:
        auto f = (arg1 % 2 == 1);
this works:
        std::cout << f(x) << '\n';
        std::cout << f(y) << '\n';
while this fails:
        std::cout << f(1) << '\n';
        std::cout << f(2) << '\n';
I'm guessing this must be for the same reason the above attempts fail.

Another question is, what's the "proper" type of "f" assuming non-C++11 
compiler? I'd like to avoid wrappers like boost::function (assuming 
that's even possible).
Later on, I'd like to return such an "f" from a function, hence the 
question (in C++11 I can get away with decltype for short and easy ones, 
i.e., prototypes like this "auto newActor() -> decltype((arg1 % 2 == 
1))" work, but this becomes inconvenient for longer bodies).

A concoction like this compiles but doesn't produce an output:
        auto f = (val(arg1) % 2 == 1);
        std::cout << f(val(0)) << '\n';
// and I'm guessing this is very wrong anyway due to unusual behavior.

Best,

Matt