Heya Boosters, I ran into a problem using boost::bind yesterday and, although I found a workaround, I've got a few questions. For the record I'm using boost 1.30. I stumbled onto the issue that boost::bind doesn't define the argument_type typedef (I was trying to use std::not1). After trawling the web I found a discussion, and useful workaround, about this here: http://tinyurl.com/5bl9m Questions that arose from this: o Why doesn't boost::bind support argument_type? o What other standard library function adapters does this affect? - Is it all that are derived from unary_function? o Has the operator! addition been incorporated into later versions of boost? - If not, why not? Thanks! Matt
Matt S Trentini
Heya Boosters,
I ran into a problem using boost::bind yesterday and, although I found a workaround, I've got a few questions. For the record I'm using boost 1.30.
I stumbled onto the issue that boost::bind doesn't define the argument_type typedef (I was trying to use std::not1). After trawling the web I found a discussion, and useful workaround, about this here:
Questions that arose from this:
o Why doesn't boost::bind support argument_type?
Because it doesn't know what you will pass to it ;-) Consider: struct polymorphic_function_object { template <class T> T operator()(T x) const; }; What should argument_type be in the result of bind(polymorphic_function_object(), _1) ??
o What other standard library function adapters does this affect? - Is it all that are derived from unary_function?
Any that require an argument_type typedef, I suppose.
o Has the operator! addition been incorporated into later versions of boost? - If not, why not?
Have you looked at the Boost lambda library? It incorporates all the operators. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams"
Matt S Trentini
writes: Heya Boosters,
I ran into a problem using boost::bind yesterday and, although I found a workaround, I've got a few questions. For the record I'm using boost 1.30.
I stumbled onto the issue that boost::bind doesn't define the argument_type typedef (I was trying to use std::not1). After trawling
Don't the boost::functional implementations of these function object adaptors play nicer with boost::bind? I think I've used these just for this reason in the past. Jeff F
Jeff Flinn wrote:
Don't the boost::functional implementations of these function object adaptors play nicer with boost::bind?
I'll give it a shot. But looking at the code (functional.hpp) it seems like argument_type is still used, the difference (when compared to the std adaptors) is that references to references are avoided (by using boost::call_traits). As I said, can't see it working, but I'll give it a shot when I get back to work. :) Cheers, Matt
David Abrahams wrote:
Because it doesn't know what you will pass to it ;-)
Consider:
struct polymorphic_function_object { template <class T> T operator()(T x) const; };
What should argument_type be in the result of
bind(polymorphic_function_object(), _1)
Ah. It's all become clear. :) Makes perfect sense.
Have you looked at the Boost lambda library? It incorporates all the operators.
Unfortunately I'm stuck working with VC7.0 which, as I understand, won't cut the mustard for lambda... Thanks, Matt
Matt S Trentini wrote:
o Has the operator! addition been incorporated into later versions of boost?
Not yet, but you can always use the snippet in the link you posted to add it yourself.
- If not, why not?
It will probably be in the release after 1.32. While operator! is trivial to implement, the relational operators that I also want to add are a little more involved because they interact with another experimental feature, equality comparisons of bind() function objects (required by function<>::contains).
Peter Dimov wrote:
o Has the operator! addition been incorporated into later versions of boost?
Not yet, but you can always use the snippet in the link you posted to add it yourself.
Yep, I've done just that. Thanks for providing such a neat little snippet! :)
- If not, why not?
It will probably be in the release after 1.32. While operator! is trivial to implement, the relational operators that I also want to add are a little more involved because they interact with another experimental feature, equality comparisons of bind() function objects (required by function<>::contains).
Sounds interesting! :) Cheers, Matt
participants (4)
-
David Abrahams
-
Jeff Flinn
-
Matt S Trentini
-
Peter Dimov