Is it really true that I can write bind(f, _1) > _2 but can't write _1 > _2 ?? I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"It's always a good idea to put the names of the libraries concerned in your subject line: http://boost-consulting.com/boost/more/discussion_policy.htm#effective" David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
From: David Abrahams <dave@boost-consulting.com>
Edward Diener <eddielee@tropicsoft.com> writes:
"It's always a good idea to put the names of the libraries concerned in your subject line:
Bind is the library concerned.
According to the cited page, it should have been spelled "[Bind]" (or "[bind]") rather than "Bind." -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Edward Diener <eddielee@tropicsoft.com> writes:
"It's always a good idea to put the names of the libraries concerned in your subject line:
Bind is the library concerned.
According to the cited page, it should have been spelled "[Bind]" (or "[bind]") rather than "Bind."
I wrote that text, and I always thought of the brackets (heck, all of the text) as a helpful suggestion, not a rule. Peter hasn't weighed in on this issue yet, so I guess maybe the brackets might've helped. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
According to the cited page, it should have been spelled "[Bind]" (or "[bind]") rather than "Bind."
I wrote that text, and I always thought of the brackets (heck, all of the text) as a helpful suggestion, not a rule.
When I write procmail recipes to filter things, I expect to find the brackets. Otherwise, the filters will match normal words in many cases. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
According to the cited page, it should have been spelled "[Bind]" (or "[bind]") rather than "Bind."
I wrote that text, and I always thought of the brackets (heck, all of the text) as a helpful suggestion, not a rule.
When I write procmail recipes to filter things, I expect to find the brackets. Otherwise, the filters will match normal words in many cases.
Well, sorry to inconvenience you, but we're sure not going to make the brackets a requirement. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
"It's always a good idea to put the names of the libraries concerned in your subject line:
Bind is the library concerned.
I was largely ribbing you because you often tell others, rightly I believe, to put the name of the library in the subject line. However since both bind and lambda have the bind function, this is a good example of the efficacy in doing so. I did not think, unlike lambda, that one could ever use placeholders in bind outside the call to the bind function itself. Where is this documented ?
Edward Diener <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
"It's always a good idea to put the names of the libraries concerned in your subject line:
Bind is the library concerned.
I was largely ribbing you because you often tell others, rightly I believe, to put the name of the library in the subject line. However since both bind and lambda have the bind function, this is a good example of the efficacy in doing so.
But it was in the subject line. Alone, it doesn't help.
I did not think, unlike lambda, that one could ever use placeholders in bind outside the call to the bind function itself. Where is this documented ?
http://boost-consulting.com/boost/libs/bind/bind.html#operators -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
"It's always a good idea to put the names of the libraries concerned in your subject line:
Bind is the library concerned.
I was largely ribbing you because you often tell others, rightly I believe, to put the name of the library in the subject line. However since both bind and lambda have the bind function, this is a good example of the efficacy in doing so.
But it was in the subject line. Alone, it doesn't help.
I did not think, unlike lambda, that one could ever use placeholders in bind outside the call to the bind function itself. Where is this documented ?
http://boost-consulting.com/boost/libs/bind/bind.html#operators
OK, I see it. What is _1 > _2 supposed to mean ? Do not placeholders in bind only have value when a bind function object has been called ?
Edward Diener <eddielee@tropicsoft.com> writes:
I did not think, unlike lambda, that one could ever use placeholders in bind outside the call to the bind function itself. Where is this documented ?
http://boost-consulting.com/boost/libs/bind/bind.html#operators
OK, I see it. What is _1 > _2 supposed to mean ?
To me it's supposed to mean roughly the same thing as in Boost.Lambda.
Do not placeholders in bind only have value when a bind function object has been called ?
?? Have a value? They are objects in many ways just like any other object. We can define the overloaded operators on them just like the overloaded operators on bind_t instances are defined. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Aug 3, 2005, at 6:21 PM, David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
That is a really interesting suggestion, and significantly blurs the line between bind and lambda. Once you have: _1 > _2 then _1 > literal will pretty much come in for free (I think). -Howard
Howard Hinnant <hinnant@twcny.rr.com> writes:
On Aug 3, 2005, at 6:21 PM, David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
That is a really interesting suggestion, and significantly blurs the line between bind and lambda.
Once you have:
_1 > _2
then
_1 > literal
will pretty much come in for free (I think).
And if you construct the types of _1 and bind(...) smartly, you get all the operators on placeholders for free, too. As in MPL, _N would be a bind_t specialization that returns its Nth argument. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Howard Hinnant <hinnant@twcny.rr.com> writes:
Once you have:
_1 > _2
then
_1 > literal
will pretty much come in for free (I think).
And if you construct the types of _1 and bind(...) smartly, you get all the operators on placeholders for free, too. As in MPL, _N would be a bind_t specialization that returns its Nth argument.
Both _1 > _2 and _1 > literal can be free for a TR1 bind where operator< is SFINAE'd on is_placeholder<L> || is_bind_expression<L> || is_placeholder<R> || is_bind_expression<R>. There isn't any need to limit the types of _1 or bind(...).
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
Thanks for the info. What abut the trick of making the placeholders references in an unnamed namespace to objects in a named one? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs.
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
Thanks for the info.
What abut the trick of making the placeholders references in an unnamed namespace to objects in a named one?
The problem is that on some compilers we can't define objects in precompiled headers. This is not an issue for TR1 because the placeholders are only declared 'extern' in the header, only for the Boost implementation ("least common denominator" for historical reasons :-)
Peter Dimov <pdimov <at> mmltd.net> writes:
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
Peter, is there still a good reason for this implementation detail? If people could write: *_1 < *_2 it would make a killer demo. I would personally scramble to implement this in time for 1.34 if you tell me there's a possibility. -Dave
David Abrahams wrote:
Peter Dimov <pdimov <at> mmltd.net> writes:
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
Peter, is there still a good reason for this implementation detail?
The reason is still as stated above. :-)
If people could write:
*_1 < *_2
it would make a killer demo.
*_1 < *_2 is different, as the subexpression *_1 requires return type deduction. This is Lambda territory at the moment; Boost.Bind doesn't do deduction.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Peter Dimov <pdimov <at> mmltd.net> writes:
David Abrahams wrote:
Is it really true that I can write
bind(f, _1) > _2
but can't write
_1 > _2
??
A limitation of the current implementation. On some compilers, the placeholders are function pointers and _1 > _2 can't be overloaded. There's no other technical reason that prevents _1 > _2 (or _1 > 0) from working; it'd fall out of the specification.
Peter, is there still a good reason for this implementation detail?
The reason is still as stated above. :-)
I mean, is there a reason that borland and GCC need to use function pointers?
If people could write:
*_1 < *_2
it would make a killer demo.
*_1 < *_2 is different, as the subexpression *_1 requires return type deduction. This is Lambda territory at the moment; Boost.Bind doesn't do deduction.
Yeah, OK. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Peter Dimov" <pdimov@mmltd.net> writes:
*_1 < *_2 is different, as the subexpression *_1 requires return type deduction. This is Lambda territory at the moment; Boost.Bind doesn't do deduction.
Yeah, OK.
If you could stand a dependency on pointee.hpp, bind /could/ do deduction for this very important operator. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
"Peter Dimov" <pdimov@mmltd.net> writes:
*_1 < *_2 is different, as the subexpression *_1 requires return type deduction. This is Lambda territory at the moment; Boost.Bind doesn't do deduction.
Yeah, OK.
If you could stand a dependency on pointee.hpp, bind /could/ do deduction for this very important operator.
Currently bind doesn't do any deduction; its objects always have a result_type. If I make *_1 work, I may as well just go ahead and create a mini-lambda. :-) Why duplicate the Lambda library?
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
"Peter Dimov" <pdimov@mmltd.net> writes:
*_1 < *_2 is different, as the subexpression *_1 requires return type deduction. This is Lambda territory at the moment; Boost.Bind doesn't do deduction.
Yeah, OK.
If you could stand a dependency on pointee.hpp, bind /could/ do deduction for this very important operator.
Currently bind doesn't do any deduction; its objects always have a result_type. If I make *_1 work, I may as well just go ahead and create a mini-lambda. :-) Why duplicate the Lambda library?
Because lambda doesn't work smoothly shared_ptr et al., for one. And it's not as portable. I've been waiting too long for phoenix-2, I guess :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
David Abrahams -
Edward Diener -
Howard Hinnant -
Peter Dimov -
Rob Stewart