On Sun, Jul 15, 2012 at 1:23 PM, Nathan Ridge <zeratul976@hotmail.com> 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