On 4/9/07, Peter Dimov <pdimov@mmltd.net> wrote:
Andrey Semashev wrote:
But will it work with lambda? I.e. will this work:
using namespace std; using namespace boost;
for_each(v.begin(), v.end(), lambda::var(cout) << _1);
Note the placeholder is not lambda::_1.
No, this won't work, unfortunately. Lambda doesn't work with Bind's placeholders. I don't know how difficult it'd be to make it support is_placeholder.
I'm still working on adding TR1 result_of compatibility to lambda, and I think I'll try adding TR1 placeholder and bind compatibility at the same time. They're all defined in <funcitonal> and to make one work nicely you kind of need to look at the other two. At least, I keep finding myself looking at them. Hopefully, Peter's specializations of is_placeholder will help things along, and it won't be too difficult, though writing test cases for this stuff is time consuming. My intention is to add the TR1 functionality to the current lambda conventions without breaking existing user code. I think this could be useful as a transition to the upcoming merged lambda/Phoenix. It will give users a chance to start using TR1 with lambda without forcing them to. If users are informed that the pre-TR1 conventions are deprecated, then during the Phoenix merger you won't have to worry about backwards compatibility. Users will have already been warned and had a chance to upgrade their code to use TR1. With regard to result_of, I'm planning on changing the documentation to say that the sig member template is deprecated, and user's should employ the TR1-style result member template. When I submit these changes for the list's consideration would you prefer that lambda's placeholders and lambda::bind also be documented as deprecated in favor of their TR1 counterparts; i.e. looking to the future with the new standard, should lambda duplicate the new standard library's functionality? Daniel