On Mon, Jul 9, 2012 at 4:12 AM, Thomas Heller wrote:

std::for_each(tokens.begin(), tokens.end(), phx::push_back(&string_tokens,

...

phx::arg_names::arg1));

This compiles but nothing is placed into string_tokens. So I'm assuming the argument from for_each isn't being passed to push_back. What needs to changed in this method call?

I am surprised this even compiles. What you want is to pass a reference to string_tokens into the phoenix expression:

You're right. I didn't copy the line correctly. There shouldn't be a reference for string_tokens.

phx::push_back(phx::ref(**string_tokens, phx::arg_names::arg1)

This fixed the problem. 3. Can that entire line of question 2 be replaced with the lazy version of

...

the method calls or does the outer most call need to be a non-lazy method?

phx::for_each(phx::arg_names::**arg1, phx::push_back(phx::arg_names:** :arg2, phx::arg_names::arg3))(tokens, string_tokens, ???);

If the entire line can be a lazy version then how would I map for_each to push_back for arg3?

use phx::lambda for the lambda function phx::for_each shall call:

phx::for_each(phx::arg_names::**arg1, phx::lambda(phx::local_**variable:: _a = phx::ref(string_tokens))[phx::**push_back(phx::local_variable:**:_a, phx::arg_names::_1)])(tokens);

Man that is ugly. I expected using only pure lazy methods to clean up the call. Why did the lambda become necessary? When reading the documentation for "Lazy Functions" it says "The library is chock full of STL savvy, predefined lazy functions covering the whole of the STL containers, iterators and algorithms." When you travel to the STL link for algorithms it doesn't mention needing the Phoenix Lambda's to make these work. Why did the phx::for_each method expect a phx::lambda method instead of being able to take the phx::push_back directly? After your help with the phx::ref I would have expected the following to work. It doesn't, I tried. phx::for_each(phx::ref(tokens), phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1)); So, I have two clean looking method calls but one doesn't work. I have a pure lazy use of methods that works but doesn't look like a clean call at all. //1. Doesn't work but looks clean. Preferred if it could work. phx::for_each(phx::ref(tokens), phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1)); //2. Works and looks clean but has the iterator range as part of the call. std::for_each(tokens.begin(), tokens.end(), phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1)); //3. Works but looks more complicated than it should. phx::for_each(phx::arg_names::**arg1, phx::lambda(phx::local_**variable::_a = phx::ref(string_tokens))[phx::**push_back(phx::local_variable:**:_a, phx::arg_names::_1)])(tokens); What is the advantage of method call 3? If you had to chose between option 2 and 3, why would you chose option 3? Ryan

On Mon, Jul 9, 2012 at 2:40 PM, Nathan Ridge wrote:

...

//2. Works and looks clean but has the iterator range as part of the call. std::for_each(tokens.begin(), tokens.end(), phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1));

Using the Boost.Range library, that would be:

boost::for_each(tokens, phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1));

I think that's about as clean as you can get.

That looks great. Any idea what concept I'm not understand in which Phoenix for_each and push_back can't be used together without the lambda? Ryan

On Mon, Jul 9, 2012 at 2:57 PM, Nathan Ridge wrote:

Actually that's not true. Without using Phoenix at all, just using Boost.Range, this is simply:

boost::push_back(string_tokens, tokens);

Interesting, I'll have to take a look at boost range. As for your question about why Phoenix for_each requires a lambda, I'm

afraid I don't understand Phoenix well enough to answer that. Perhaps Thomas can help us.

Lets hope he weighs in then. I would really like to understand this sticking point. Ryan

On 7/10/2012 6:21 AM, Jeffrey Lee Hellrung, Jr. wrote:

On Mon, Jul 9, 2012 at 3:07 PM, Ryan mailto:boost@qwerkle.com> wrote:

On Mon, Jul 9, 2012 at 2:57 PM, Nathan Ridge mailto:zeratul976@hotmail.com> wrote:

Actually that's not true. Without using Phoenix at all, just using Boost.Range, this is simply:

boost::push_back(string_tokens, tokens);

Interesting, I'll have to take a look at boost range.

As for your question about why Phoenix for_each requires a lambda, I'm afraid I don't understand Phoenix well enough to answer that. Perhaps Thomas can help us.

Lets hope he weighs in then. I would really like to understand this sticking point.

I'm pretty sure it's a scoping issue. Your inner and outer arg1's should actually bind at different times to different objects, and the only way to signify that is to use scope the inner arg1 in a phx::lambda construct.

[...] Yes, it's a scoping issue. Please read up: http://tinyurl.com/brufnnw In essence, anytime you need a higher-order function passed in as an argument (e.g. for_each's function argument), you'll need an explicit lambda. The for_each example is actually mentioned in the docs: http://tinyurl.com/cjy82f8 It's really not that bad as you characterized it. Explicit is always better than implicit. For example: for_each(arg1, lambda[cout << arg1]) This other example (again from the docs) *cannot* be done with an implicit (unscoped) syntax. Nor can this be done with the mechanisms in MPL or Boost.Lambda, for example: for_each(arg1, lambda(_a = arg2) [ push_back(arg1, _a) ] ) Only the de-Bruijn syntax can do this as well. Please read up before you bash the thing ;-) Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

On 7/10/2012 7:24 AM, Jeffrey Lee Hellrung, Jr. wrote:

On Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman mailto:joel@boost-consulting.com> wrote: [...]

Only the de-Bruijn syntax can do this as well. Please read up before you bash the thing ;-)

OT: I can't tell if this was directed at me or the OP, and what was or could be bashed, but I certainly didn't intend to bash neither Phoenix nor de Bruijn syntax!

Pardon me, it's not directed at you :-) For reference: Ryan wrote:

Man that is ugly. I expected using only pure lazy methods to clean up the call. Why did the lambda become necessary?

Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

On Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman wrote:

Yes, it's a scoping issue. Please read up:

http://tinyurl.com/brufnnw

I apologize for not seeing this sooner. I got to the STL Algorithm page through the Lazy Functions page in the Starter Kit. This in essence skipped over some of the documentation and it didn't occur to me that I was missing information. Please read up before you bash the thing ;-)

I didn't mean to sound harsh. I gave a gut reaction about the needed syntax to accomplish what I considered a simple task. I apologize if it sounded like an attack on the library. That was not my intent. I really do appreciate all the hard work that goes into these libraries.

Actually, it could be simply:

for_each(_1, lambda [ push_back(ref(string_tokens), _1) ]

)

Thank you for simplifying it even further. I tried it and it compiles and works. I did tried and reduce it even further. for_each( ref(tokens), lambda [ push_back(ref(string_tokens), _1) ] ) This compiled but didn't work as intended. Why is push_back able take a reference to string_tokens but for_each isn't able to take a reference to tokens? Ryan

On Tue, Jul 10, 2012 at 7:02 PM, Joel de Guzman wrote:

Hmm, I can never tell unless I see a minimal cpp file I can try.

I've included a minimal .cpp that produces the undesired behavior. Ryan

On Wed, Jul 11, 2012 at 4:08 PM, Joel de Guzman wrote:

On 7/12/2012 12:38 AM, Ryan wrote:

...

On Tue, Jul 10, 2012 at 7:02 PM, Joel de Guzman < joel@boost-consulting.com >> wrote:

Hmm, I can never tell unless I see a minimal cpp file I can try.

I've included a minimal .cpp that produces the undesired behavior.

Sorry I can't find it. Could you point me to it again, please?

I've tried including it again. Ryan

On Thu, Jul 12, 2012 at 6:46 PM, Joel de Guzman wrote:

You did not evaluate it. Try adding a () at the end:

phx::for_each(phx::ref(tokens)**, phx::lambda [ phx::push_back(phx::ref(**string_tokens), phx::arg_names::arg1) ] )();

Adding the evaluation worked. I get the expected results now. I now have the simplest pure phoenix method to parse a boost tokenizer into a vector of strings. Is there a helper method that can be written to automatically append the phx::lambda in this case. This would give the following results. phx::for_each(phx::ref(tokens), phx::push_back(phx::ref(string_tokens), phx::arg_names::arg1))(); I understand the advantage of the lambda section. It allows added variables to be created and more complicated requirements to be accomplished. I just want to try and remove the extra syntax from my users view if it isn't necessary (other than to make it work :) ). I would think it's possible if the argument from one method is being used directly in the other method without creating any additional variables. Like I said, I'm not sure if this is possible but would like to try if it is. Ryan

On Sun, Jul 15, 2012 at 1:23 PM, Nathan Ridge wrote:

I don't see why you insist on using phoenix::for_each.

I'm trying to gain an understanding of the phoenix library. This is an easy example that I have in my code to tear apart. I know the end result and there are only two functions that I'm varying. The advantage of phoenix::for_each over boost::for_each is that phoenix::

for_each is lazy (it allows you to delay some of the arguments to be passed in later). You are not making use of that feature here - you are providing all of the arguments up-front, and as a result, you have to call the resulting delayed function with no arguments.

True. I'm not taking full advantage of the Phoenix library. I find it easier to know when to use a lazy for_each when I see how it plays with other things. You should only use the lazy version of a function when you are taking

advantage of the fact that it's lazy; in other cases it's simpler to use the regular, non-lazy version. In this case, you need push_back() to be lazy, but not for_each(), so you are complicating things unnecessarily by using the phoenix version of for_each.

I agree. Again I view this as a learning experience. If I started with a very complicated problem I might not understand the library enough to find the solution.

This works just fine, as I've mentioned before:

boost::for_each(tokens, phx::push_back(phx::ref(string_tokens), phx::arg_names::arg)));

This will probably be the method I go with in the end. Note that it is not inconsistent that you are using boost::for_each for

one algorithm, and phoenix::push_back for another. The phoenix:: algorithms are exactly like the boost:: algorithms except that they add laziness. Since adding laziness complicates the interface of the function, it follows that you should only use the lazy version in instances where you actually need the laziness.

I have no problem using the boost::for_each, std::for_each or the phoenix::for_each. Unfortunately, I didn't understand the phoenix::for_each. Ryan

On 7/16/2012 1:38 AM, Ryan wrote:

I understand the advantage of the lambda section. It allows added variables to be created and more complicated requirements to be accomplished. I just want to try and remove the extra syntax from my users view if it isn't necessary (other than to make it work :) ). I would think it's possible if the argument from one method is being used directly in the other method without creating any additional variables.

What API do you intend to make visible? I am not sure yet what it is you are trying to do and want your users to see. I'm sure you can write a wrapper that will hide these things. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com