Re: [Boost-bugs] [Boost C++ Libraries] #9742: for_each causes funny behavior in phoenix V3 expressions

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9742: for_each causes funny behavior in phoenix V3 expressions
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-04-02 22:21:26


#9742: for_each causes funny behavior in phoenix V3 expressions
-------------------------------+-----------------------------------
  Reporter: Chromatix | Owner: theller
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: phoenix
   Version: Boost 1.54.0 | Severity: Problem
Resolution: | Keywords: phoenix,for_each,lazy
-------------------------------+-----------------------------------

Comment (by John Fletcher <J.P.Fletcher@…>):

 Thank you. I was just reading the mailing list thread and saw it had
 suggested returning void. I arrived at my conclusions by working with the
 phoenix example code 'container_actor' and comparing a size_impl functor
 which works with the for_each code. I have looked into what is happening
 at the Proto level, and the code in the bracket is passed to a set of
 comma operators. There is a Proto operation called display_expr() which
 makes this clear. The ones containing the return object from for_each get
 wrongly processed, that is if it is (a,b) then b gets processed before a,
 but only by some compilers and only sometimes. My tests on develop work
 when I don't expect them to. Changing to the void return removes the
 problem. I need to explore why this happens with the other developers.

 When I have implemented a solution I will post it here. I want to make the
 return object available for cases where it is needed.

 Would you let me know what other cases fail? I think you said that there
 were problems with my for_ solution but I cannot reproduce those with gcc
 on Linux.

 Thank you.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9742#comment:12>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:15 UTC