non-mutable local variables in phoenix

[anonymous]

Phoenix local variables are non-mutable with the test case below. It seems like making a local variable non-mutable in these cases is the wrong thing to do.

If you follow my logic:

• TEST1 -- the local is a ref to the variable i
• TEST2 -- the local is an int containing the value from arg1 or i (and is mutable)
• TEST3 -- I would expect the local to be an into containing the value from arg1... but it doesn't compile because it things the local is immutable
• TEST4 -- I would expect this to work the same as TEST3

#define TEST3

#include <iostream>
#include <boost/phoenix/phoenix.hpp>

int main()
{
   using namespace boost::phoenix;
   using namespace boost::phoenix::arg_names;
   using namespace boost::phoenix::local_names;


#ifdef TEST1
   std::cout << "TEST1" << std::endl;
   /**
    *   This will print 41 41.
    *   _a is a local variable that is a reference to i. This is a little surprising
    *   at first but not too bad. We can deal with it.
    */
   int i = 42;
   let( _a = arg1 )
   [
      std::cout << --_a
   ](i);

   std::cout << ' ' << i << std::endl;

#endif // TEST1


#ifdef TEST2
   std::cout << "TEST2" << std::endl;
   /**
    *   This will print 41 42.
    *   _a is a local variable initialized with the value of arg1. Makes sense
    */
   int i = 42;
   let( _a = val(arg1) )
   [
      std::cout << --_a
   ](i);

   std::cout << ' ' << i << std::endl;

#endif // TEST2



#ifdef TEST3
   std::cout << "TEST3" << std::endl;
   /**
    *   This wont compile because _a is not mutable. This is not only
    *   surprising but makes local scoped variables have very limited use.
    */
   let( _a = val(arg1) )
   [
      std::cout << --_a
   ](42);

#endif // TEST3



#ifdef TEST4
   std::cout << "TEST4" << std::endl;
   /**
    *   This fails for the same reason... I would expect it to work also.
    */
   let( _a = val(42) )
   [
      std::cout << --_a
   ]();

#endif // TEST4


   return 1;
} 

[anonymous]

Everything is working as expected.

Test 1: --_a ==> result is 41, will print 41 Because it is captured by reference, it will have a side effect on i

Test 2: i is captured by value, it will be decremented, but this change won't be "noticed" by the value-captured i. Correct behavior.

Test 3 and Test 4: They actually compile and return the expected result

These changes have been made just recently (a few hours ago), you might update your working copy.

[Thomas Heller]

the previous comment was by me ... login fail.

[Michael Caisse]

Hi Thomas -

Yes, Test1 and Test2 worked "correctly".

Test3 and Test4 were not compiling with the version of trunk I was using. I have updated and it is working as expected now.

Thanks for the fast turn around!