[bind] Request: use result_of instead of result_type for functors
One of the drawbacks of using functors with Boost.Bind is that the result type of the functor must be specified either as a typedef inside the functor's definition or as a template argument when building the binding. As the documentation states it: "In the general case, the return type of the generated function object's operator() has to be specified explicitly (without a typeof operator the return type cannot be inferred)" It seems that result_of() would be a good implementation of the "typeof" operator referenced in the above, instead of relying upon a single result_type typedef inside the functor struct/class. This would allow the use of functors whose result type depends upon the arguments passed to the functor. It looks like there was a proof-of-concept patch submitted for this a couple years ago: https://svn.boost.org/trac/boost/ticket/4542 It doesn't appear to have received any attention, however. Is this something that might happen? -- View this message in context: http://boost.2283326.n4.nabble.com/bind-Request-use-result-of-instead-of-res... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, Feb 5, 2013 at 8:57 AM, Jason <jasonr@3db-labs.com> wrote:
One of the drawbacks of using functors with Boost.Bind is that the result type of the functor must be specified either as a typedef inside the functor's definition or as a template argument when building the binding. As the documentation states it:
"In the general case, the return type of the generated function object's operator() has to be specified explicitly (without a typeof operator the return type cannot be inferred)"
It seems that result_of() would be a good implementation of the "typeof" operator referenced in the above, instead of relying upon a single result_type typedef inside the functor struct/class. This would allow the use of functors whose result type depends upon the arguments passed to the functor. It looks like there was a proof-of-concept patch submitted for this a couple years ago:
https://svn.boost.org/trac/boost/ticket/4542
It doesn't appear to have received any attention, however. Is this something that might happen?
My guess: probably not, given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind. - Jeff
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place. -- Eric Niebler Boost.org
On Tue, Feb 5, 2013 at 11:09 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place.
Can you elaborate? - Jeff
On 13-02-06 09:30 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Feb 5, 2013 at 11:09 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place.
Can you elaborate?
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf). If Boost.Bind meets my needs (and std::bind is not available), I use it. Eric -- Eric Niebler Boost.org
Eric Niebler-4 wrote
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks for clearing up the differences. In my ignorance, I actually wasn't even aware of Boost.Phoenix.Bind. It looks like it is functionally equivalent to my original request: Boost.Bind-like functionality where result_of is used internally to allow functors with multiple overloads of operator(). I appreciate the comments. Jason -- View this message in context: http://boost.2283326.n4.nabble.com/bind-Request-use-result-of-instead-of-res... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, Feb 6, 2013 at 9:40 AM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-06 09:30 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Feb 5, 2013 at 11:09 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place.
Can you elaborate?
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks, makes sense, except I wasn't aware that Boost.Phoenix used any kind of decltype-like mechanism... - Jeff
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks, makes sense, except I wasn't aware that Boost.Phoenix used any kind of decltype-like mechanism...
- Jeff
Surely Boost.Phoenix.Bind doesn't *require* a decltype-like mechanism ifyou follow the result_of protocol, does it? Regards,Nate
On 13-02-06 02:51 PM, Nathan Ridge wrote:
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks, makes sense, except I wasn't aware that Boost.Phoenix used any kind of decltype-like mechanism...
Surely Boost.Phoenix.Bind doesn't *require* a decltype-like mechanism ifyou follow the result_of protocol, does it? Regards,Nate
That's true, Phoenix bind can (and AFAIK does) just use boost::result_of. Of course, boost::result_of may in fact use decltype. result_of never uses Boost.TypeOf. Other parts of Phoenix do use decltype or TypeOf. -- Eric Niebler Boost.org
On 2/7/13 6:51 AM, Nathan Ridge wrote:
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks, makes sense, except I wasn't aware that Boost.Phoenix used any kind of decltype-like mechanism...
- Jeff
Surely Boost.Phoenix.Bind doesn't *require* a decltype-like mechanism ifyou follow the result_of protocol, does it? Regards,Nate
Phoenix *bind* does not use decltype nor Boost.TypeOf. Phoenix uses Boost.TypeOf (which uses decltype when available) to deduce types on operations such as (_1 * _2). Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 2/7/13 2:40 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Wed, Feb 6, 2013 at 9:40 AM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-06 09:30 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Feb 5, 2013 at 11:09 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place.
Can you elaborate?
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
Thanks, makes sense, except I wasn't aware that Boost.Phoenix used any kind of decltype-like mechanism...
It does not use decltype. It does, however, use Boost.TypeOf in some places for type deduction, which in turn uses decltype when available. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On Wed, Feb 6, 2013 at 12:40 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-06 09:30 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Feb 5, 2013 at 11:09 PM, Eric Niebler <eniebler@boost.org> wrote:
On 13-02-05 05:21 PM, Jeffrey Lee Hellrung, Jr. wrote:
given that Boost.Bind has been largely superseded by Boost.Phoenix.Bind.
I'd like to address just this part. It's not true, AFAIK. Boost.Bind still has its place.
Can you elaborate?
Boost.Bind is a smaller, simpler library that pulls in less code and has fewer dependencies. It also doesn't do anything that would require decltype, or an emulation thereof (Boost.TypeOf).
If Boost.Bind meets my needs (and std::bind is not available), I use it.
If boost::phoenix::bind is much more useful/powerful could there be a note mentioning it in the boost::bind documentation? Cheers! Andrew Hundt
participants (6)
-
Andrew Hundt -
Eric Niebler -
Jason -
Jeffrey Lee Hellrung, Jr. -
Joel de Guzman -
Nathan Ridge