On Fri, Feb 15, 2008 at 3:14 AM, Jean-Pierre Bergamin wrote:

Could there be a way to provide a function object safe_logical_and that only evaluates the second argument if the first one is true?

I've written something like that before as: // warning, code typed in e-mail template struct and_ { F0 first; F1 second; and_(F0 f0, F1, f1) : first(f0), second(f1) { } bool operator()() const { return first() && second(); } }; but if you needed function arguments that weren't available to be bound at and_ construction time you'd have to do some more trickery. This would also scale well using variadic templates. --Michael Fawcett

On Fri, Feb 15, 2008 at 10:19 AM, dizzy wrote:

On Friday 15 February 2008 17:07:21 Michael Fawcett wrote:

...

On Fri, Feb 15, 2008 at 3:14 AM, Jean-Pierre Bergamin wrote:

...

Could there be a way to provide a function object safe_logical_and that only evaluates the second argument if the first one is true?

I've written something like that before as:

<snip code with typos>

...

but if you needed function arguments that weren't available to be bound at and_ construction time you'd have to do some more trickery. This would also scale well using variadic templates.

I don't understand how this code does not evaluate the second argument if the first one isn't true (the previous poster explicitely requested that). When you construct the above functor evaluation of the expression given for "f1" argument will happen which may run into UB, ie the classical "if (p && p->flag)" idiom is broken (and you seem to recognize that... no idea then what you ment with the code).

I might be showing my misunderstanding of all the intricacies at work here... Maybe I am not understanding his intents, or maybe we are talking to two different points? I have pasted below his original code, modified to use something like what I posted (and also to have a result when && is used). Are you saying that short-circuit evaluation doesn't happen here, i.e. the second(t) call happens no matter what? I thought it was understood that overloading && would have that effect, and the OP understood that too, which is why he suggested a safe_logical_and. That means overloading && is out of the question, which we all seem to agree on, but I am feeling a little silly trying to figure out why the below code is rubbish. #include "boost/bind.hpp" #include <algorithm> #include <iostream> #include <string> #include <vector> using namespace std; using namespace boost; struct employee { employee(int id, const string &name) : id(id), name(name) {} int id; string name; }; ostream &operator<<(ostream &o, const employee &e) { o << e.id << " - " << e.name << endl; return o; } template struct and_ { F0 first; F1 second; and_(F0 f0, F1 f1) : first(f0), second(f1) { } template <typename T> bool operator()(const T &t) const { return first(t) && second(t); } }; template struct or_ { F0 first; F1 second; or_(F0 f0, F1 f1) : first(f0), second(f1) { } template <typename T> bool operator()(const T &t) const { return first(t) || second(t); } }; template and_ safe_logical_and(F0 f0, F1 f1) { return and_(f0, f1); } template or_ safe_logical_or(F0 f0, F1 f1) { return or_(f0, f1); } int main() { typedef vector<employee> emp_container; emp_container staff; staff.reserve(4); staff.push_back(employee(1, "John")); staff.push_back(employee(2, "Paula")); staff.push_back(employee(3, "Sara")); staff.push_back(employee(4, "Geroge")); emp_container::const_iterator e = find_if(staff.begin(), staff.end(), safe_logical_and(safe_logical_or(bind(&employee::name, _1) == "Paula", bind(&employee::name, _1) == "John"), bind(&employee::id, _1) <= 4)); if (e != staff.end()) { cout << "Found: " << *e << endl; } } --Michael Fawcett

Marshall Clow:

At 8:12 PM +0100 2/14/08, Jean-Pierre Bergamin wrote:

...

Hello everyone

Is there a reason why boost::bind does not overload the logical operators || and &&? They definitively would come in more handy to build up complicated logical expressions than using the std::logical_and and std::logical_or function objects.

My guess is that since boost::bind could not replicate the behavior of && and ||, the authors decided not to provide them.

The built in && will not evaluate the second argument if the first is false. Similarly, the built in || will not evalulate the second argument if the first is true.

You are absolutely right. I couldn't think of an elegant way to replicate the behavior of the built-in logical operators at the time I added support for the rest. This thread did spark my interest though and I was able to add && and || to the trunk, complete with the proper short-circuit semantics.

Richard:

[Please do not mail me a copy of your followup]

boost-users@lists.boost.org spake the secret code <011a01c87003$0ff77eb0$6407a80a@pdimov2> thusly:

...

[...] This thread did spark my interest though and I was able to add && and || to the trunk, complete with the proper short-circuit semantics.

Can you elaborate on the approach you took? I thought it was essentially impossible to replicate the short-circuit semantics with your own user-defined operator|| and operator&&.

It is impossible to overload && in such a way so that in e1 && e2, e2 is not evaluated when e1 is false. But it's possible to overload f && g so that in (f && g)(x) :- f(x) && g(x), g(x) is not evaluated when f(x) is false.

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <019801c8721d$e1612fc0$6407a80a@pdimov2> thusly:

It is impossible to overload && in such a way so that in e1 && e2, e2 is not evaluated when e1 is false. But it's possible to overload f && g so that in (f && g)(x) :- f(x) && g(x), g(x) is not evaluated when f(x) is false.

I guess I'm still a little lost... why does it work for f && g and not e1 && e2? Is it because f and g are functors and don't evaluate their expressions until their operator() is called? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/

Richard wrote:

[Please do not mail me a copy of your followup]

boost-users@lists.boost.org spake the secret code <019801c8721d$e1612fc0$6407a80a@pdimov2> thusly:

...

It is impossible to overload && in such a way so that in e1 && e2, e2 is not evaluated when e1 is false. But it's possible to overload f && g so that in (f && g)(x) :- f(x) && g(x), g(x) is not evaluated when f(x) is false.

I guess I'm still a little lost... why does it work for f && g and not e1 && e2? Is it because f and g are functors and don't evaluate their expressions until their operator() is called?

Yes, and because (f && g) returns another function object, whose operator() can first evaluate f(x) then decide whether to evaluate g(x). Jeff Flinn