[Phoenix] for_each calling push_back for stl containers
Hello, In upgrading from boost 1.39 to 1.47 I changed my use of the Phoenix library (which was within Spirit) to the stand alone Phoenix library. This caused my below code to stop working. /**** Code Start ***/ static boost::char_separator<char> seperator(":"); boost::tokenizer< boost::char_separator<char> > tokens(s, seperator); //s is a passed in std::string std::vector<std::string> string_tokens; namespace phx = boost::phoenix; //This line fails to compile now. std::for_each(tokens.begin(), tokens.end(), phx::bind(&std::vector<std::string>::push_back, &string_tokens, phx::arg_names::arg1)); /**** Code Stop ***/ This lead me to three questions. 1. What changed about phoenix bind that caused this not to work any more? 2. I tried using the lazy version of push_back to bypass the bind issue. In the documentation there are not any examples of multiple algorithm and container methods calling each other to show how the arguments of one method is passed to another. 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? 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? Any help for these three questions would really be appreciated. Ryan
On 07/08/2012 11:16 PM, Ryan wrote:
Hello,
In upgrading from boost 1.39 to 1.47 I changed my use of the Phoenix library (which was within Spirit) to the stand alone Phoenix library. This caused my below code to stop working.
/**** Code Start ***/ static boost::char_separator<char> seperator(":"); boost::tokenizer< boost::char_separator<char> > tokens(s, seperator); //s is a passed in std::string std::vector<std::string> string_tokens;
namespace phx = boost::phoenix; //This line fails to compile now. std::for_each(tokens.begin(), tokens.end(), phx::bind(&std::vector<std::string>::push_back,&string_tokens, phx::arg_names::arg1)); /**** Code Stop ***/
This lead me to three questions.
1. What changed about phoenix bind that caused this not to work any more? I don't know, to be honest. I am surprised this worked at all. push_back is overloaded which can't really be handled that well with bind.
2. I tried using the lazy version of push_back to bypass the bind issue. In the documentation there are not any examples of multiple algorithm and container methods calling each other to show how the arguments of one method is passed to another.
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:
phx::push_back(phx::ref(string_tokens, phx::arg_names::arg1)
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);
Any help for these three questions would really be appreciated.
Hope that helps.
Ryan
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, Jul 9, 2012 at 4:12 AM, Thomas Heller <thom.heller@googlemail.com>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
//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. Regards, Nate
On Mon, Jul 9, 2012 at 2:40 PM, Nathan Ridge <zeratul976@hotmail.com> 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
//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.
Actually that's not true. Without using Phoenix at all, just using Boost.Range, this is simply: boost::push_back(string_tokens, tokens); 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. Regards, Nate
On Mon, Jul 9, 2012 at 2:57 PM, Nathan Ridge <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. Ryan
On Mon, Jul 9, 2012 at 3:07 PM, Ryan <boost@qwerkle.com> wrote:
On Mon, Jul 9, 2012 at 2:57 PM, Nathan Ridge <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. I don't remember exactly what you were trying to do, but I believe it was something like phx::for_each(arg1, phx::push_back(dest, arg1))(srce) which evaluates to approximately for_each(srce, F) where F(x) evaluates dest.push_back(srce) (regardless of x) every time, since the arg1 in phx::push_back(dest, arg1) is immediately bound to srce. phx::lambda effectively delays this binding to give you what you want: phx::for_each(arg1, phx::lambda(phx::push_back(dest, arg1)))(srce) => for_each(srce, phx::push_back(dest, arg1)) Note that my syntax is way off here, but this scoping issue is present not just in Boost.Phoenix but also Boost.MPL and probably Boost.Bind/Std.Bind. Also consider reading up on de Bruijn indices on wikipedia; at some point in the past on this list, someone proposed using de Bruijn placeholders to avoid phx::lambda (and Phoenix local variables) acrobatics. HTH, - Jeff
On 7/10/2012 6:21 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jul 9, 2012 at 3:07 PM, Ryan <boost@qwerkle.com <mailto:boost@qwerkle.com>> wrote:
On Mon, Jul 9, 2012 at 2:57 PM, Nathan Ridge <zeratul976@hotmail.com <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 Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman <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! - Jeff
On 7/10/2012 7:24 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman <joel@boost-consulting.com <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 7/10/2012 8:44 AM, Joel de Guzman wrote:
On 7/10/2012 7:24 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman <joel@boost-consulting.com <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?
Looking back at the code. I think it's only "ugly" as written. With proper "using" stuff, it can be clean: for_each(_1, lambda(_a = ref(string_tokens)) [ push_back(_a, _1) ] ) Actually, it could be simply: for_each(_1, lambda [ push_back(ref(string_tokens), _1) ] ) Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Mon, Jul 9, 2012 at 4:14 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Yes, it's a scoping issue. Please read up:
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 7/11/2012 2:11 AM, Ryan wrote:
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.
No worries, Ryan. Don't take me too seriously ;-) I'm half joking, you know.
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?
Hmm, I can never tell unless I see a minimal cpp file I can try. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
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 <mailto: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? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Wed, Jul 11, 2012 at 4:08 PM, Joel de Guzman <joel@boost-consulting.com>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 <mailto:joel@boost-consulting.**com <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 7/12/2012 10:17 PM, Ryan wrote:
On Wed, Jul 11, 2012 at 4:08 PM, Joel de Guzman <joel@boost-consulting.com <mailto:joel@boost-consulting.com>> 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 <mailto:joel@boost-consulting.com> <mailto:joel@boost-consulting.__com <mailto: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.
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) ] )(); Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Thu, Jul 12, 2012 at 6:46 PM, Joel de Guzman <joel@boost-consulting.com>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
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::arg)) ] )();
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::arg)))();
I don't see why you insist on using phoenix::for_each. 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. 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. This works just fine, as I've mentioned before: boost::for_each(tokens, phx::push_back(phx::ref(string_tokens), phx::arg_names::arg))); 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. Regards, Nate
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
On 7/16/2012 4:23 AM, Nathan Ridge 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::arg)) ] )();
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::arg)))();
I don't see why you insist on using phoenix::for_each.
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.
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.
This works just fine, as I've mentioned before:
boost::for_each(tokens, phx::push_back(phx::ref(string_tokens), phx::arg_names::arg)));
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.
Exactly my thoughts. I second that. There's no use in having a lazy function that you will evaluate immediately anyway. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
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
On Mon, Jul 16, 2012 at 6:32 PM, Joel de Guzman <joel@boost-consulting.com>wrote:
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.
The Phoenix API would still be visible in my code. I was trying to hide the fact I used a lambda call to combine for_each and push_back. My colleagues are familiar with the concept of combining stl algorithms together. They are not familiar with lambdas. This was to avoid confusion when others need to maintenance my code. I understand from both Nathan and you that a pure lazy method that you evaluate immediately is pointless. I'm not arguing that fact. Since this was an easy concept I wanted to understand the library for when evaluating a pure lazy method immediately isn't possible. I apologize for the confusion of what I was trying to accomplish. I've have greatly appreciated the help that everyone has provided. Ryan
participants (5)
-
Jeffrey Lee Hellrung, Jr. -
Joel de Guzman -
Nathan Ridge -
Ryan -
Thomas Heller