Roman Krylov wrote:

Brian Allison wrote:

for_each(src.begin(), src.end(),
     if_then(  bind<bool>(&vector<Rec*>::empty, &var(dst)),
               bind<void>(&vector<Rec*>::push_back, &var(dst), _1) ) );

isn't it equal to:
    if(dst.empty()) { dst.push_back(src.front()); }
? The sample is for training purposes?

Illustration purposes. The real picture involves a domain-specific language (in a very weak sense) interpreter where I wanted to reimplement the parser and the evaluaters using the Boost Libraries.

The very first step, besides becoming aware of Boost, involves the evaluater portions of the interpreter - not the language parser. So if I could learn how to use Lambda/Bind to evaluate a generic unary predicate over a set of things, then that'd be easy to generalize to the other sorts of predicates that the language contains.

I thought I was picking an example which was as simple as possible but complex enough that it would both illustrate the idea and refreain from distracting with the simplicity of an obvious straw-man. *heh* :)

   for_each(src.begin(), src.end(),
            if_then(bind<bool>(&vector<Rec*>::empty, &var(dst)),
                    (&var(dst) ->* &vector<Rec*>::push_back)(_1)
                )
            );

In either previous and in this case mere '&dst' should be used instead 
of '&var(dst)' without '(_1)' perhaps.

When I used the second form, I tried originally the forms:
bind<bool>(&vector<Rec*>::empty, dst)
bind<bool>(&vector<Rec*>::empty, &dst)
and the empty function was only evaluated one time (oppose: once per iteration). When I moved to using bind() and var(), it did what I expected - as the documentation led me to believe once I had actually read it again. I was just hoping to use the lambda syntax over the bind syntax where possible.

Ironically, the actual code from which the example comes is part of a unit test. I'm using cppunit, but if Boost::test is more helpful than eventually I'll move my unit tests from cppunit to Boost::test.

Newer, faster, small - oh how I love the technology curve. :)

thanks,
Brian