Re: [boost] boost::ref for function objects
On Friday 14 February 2003 02:56 pm, Peter Dimov wrote: > Douglas Gregor wrote: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > I'm not sure whether that last part is a good idea. > > The ref "vision" has been that in a perfect world, > > ref(f)(x, y); > > is exactly the same as > > F & rf = f; > rf(x, y); > > and the best way to accomplish that is a core change that enables all > conversion operators to be considered in function calls (currently only > conversion operators to pointers to functions are considered.) Agreed. > With this in mind, the implementation of ref(f) that relies on the typedefs > to approximate the above is fine (although it might be overkill to consider > anything beyond result_type and perhaps sig) but the ref syntax doesn't > rhyme. We need to keep in mind that ref(derived) and ref const>(5) are valid today. I can't think of any reason to write either of these last expressions, but I don't mind removing the extra syntax. Actually, this has the secondary benefit of eliminating the extra template parameter I needed to add to reference_wrapper. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
Douglas Gregor wrote: > We've discussed making boost::ref/boost::cref work for arbitrary > functions > objects before. I just committed a version of ref.hpp that supports > this > ability to the sandbox. With this code, you can write: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > or, if you don't want the return type deduced, specify it as in > Boost.Bind: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); I'm not sure whether that last part is a good idea. The ref "vision" has been that in a perfect world, ref(f)(x, y); is exactly the same as F & rf = f; rf(x, y); and the best way to accomplish that is a core change that enables all conversion operators to be considered in function calls (currently only conversion operators to pointers to functions are considered.) With this in mind, the implementation of ref(f) that relies on the typedefs to approximate the above is fine (although it might be overkill to consider anything beyond result_type and perhaps sig) but the ref syntax doesn't rhyme. We need to keep in mind that ref(derived) and ref(5) are valid today. The bind(ref(f), _1) workaround is always an option when the natural syntax fails. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Thursday 13 February 2003 10:12 am, Peter Dimov wrote: > > --Compatibility-- > > This version of ref.hpp is backwards-compatible with the existing > > version of > > ref.hpp on a compiler that can handle the new ref.hpp (needs partial > > specialization and proper SFINAE handling). At some point I'll write a > > stripped-down version that other compilers can handle. > > I tried to do this once and failed. It's hard to make operator() work on > deficient compilers (esp. the zero-arg version that is not a template) > without breaking ref(x) where x is not a function object. Yep, this is the killer. Can't try to use result_type because it might not be there, can't detect result_type on broken compilers, and can't stop the declaration from being instantiated :(. Could just go with the limitation that arity 0 function objects won't work unless a return type is specified by the user. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
Douglas Gregor wrote: > We've discussed making boost::ref/boost::cref work for arbitrary > functions > objects before. I just committed a version of ref.hpp that supports > this > ability to the sandbox. With this code, you can write: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > or, if you don't want the return type deduced, specify it as in > Boost.Bind: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > Features of this implementation: > - Return type deduction (discussed below) > - Argument type deduction (discussed below) > - Able to handle function objects that have multiple arities (e.g., > can be > invoked with 0 or 2 arguments) That's very nice! [...] > --Compatibility-- > This version of ref.hpp is backwards-compatible with the existing > version of > ref.hpp on a compiler that can handle the new ref.hpp (needs partial > specialization and proper SFINAE handling). At some point I'll write a > stripped-down version that other compilers can handle. I tried to do this once and failed. It's hard to make operator() work on deficient compilers (esp. the zero-arg version that is not a template) without breaking ref(x) where x is not a function object. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Wednesday 12 February 2003 07:15 pm, David Abrahams wrote: > Douglas Gregor <[EMAIL PROTECTED]> writes: > > We've discussed making boost::ref/boost::cref work for arbitrary > > functions objects before. I just committed a version of ref.hpp that > > supports this ability to the sandbox. With this code, you can write: > > > > std::transform(c.begin(), c.end(), out, boost::ref(f)); > > What's the key feature? Overloaded operator() on reference_wrapper? Yes. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
Douglas Gregor <[EMAIL PROTECTED]> writes: > We've discussed making boost::ref/boost::cref work for arbitrary functions > objects before. I just committed a version of ref.hpp that supports this > ability to the sandbox. With this code, you can write: > > std::transform(c.begin(), c.end(), out, boost::ref(f)); What's the key feature? Overloaded operator() on reference_wrapper? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::ref for function objects
We've discussed making boost::ref/boost::cref work for arbitrary functions objects before. I just committed a version of ref.hpp that supports this ability to the sandbox. With this code, you can write: std::transform(c.begin(), c.end(), out, boost::ref(f)); or, if you don't want the return type deduced, specify it as in Boost.Bind: std::transform(c.begin(), c.end(), out, boost::ref(f)); Features of this implementation: - Return type deduction (discussed below) - Argument type deduction (discussed below) - Able to handle function objects that have multiple arities (e.g., can be invoked with 0 or 2 arguments) The implementation is here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/boost/ref.hpp?rev=HEAD&content-type=text/plain Testcases are here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/libs/utility/ref_call_test.cpp?rev=HEAD&content-type=text/plain --Return type deduction-- - If the user specifies a return type, use it - Otherwise, if the class has a result_type typedef, use it - Otherwise, use Boost.Lambda-style sig::type --Argument type deduction-- - If typedefs arg1_type, arg2_type, ..., argN_type are available, use _precisely_ those argument types (as in Boost.Function) to define operator()(arg1_type), operator()(arg1_type, arg2_type), etc, up to 'N' for that particular class. - Otherwise, if the class has an argument_type typedef, define operator()(const argument_type&). If the class also has first_argument_type and second_argument_type, define operator()(const first_argument_type&, const second_argument_type&); - Otherwise, if the class has first_argument_type and second_argument_type, define operator()(const first_argument_type&, const second_argument_type&); - Otherwise, define a bunch of function templates that deduce the argument types at call time, e.g., template return-type-as-mentioned-before operator()(T1&, T2&, ..., TN&); There is always an operator() that takes no arguments. --Compatibility-- This version of ref.hpp is backwards-compatible with the existing version of ref.hpp on a compiler that can handle the new ref.hpp (needs partial specialization and proper SFINAE handling). At some point I'll write a stripped-down version that other compilers can handle. The stripped-down version will feel a lot more like boost::bind: - Return type deduction will be limited to using a user-supplied return type, or else using ::result_type - Argument type deduction won't look for argN_types, argument_type, or first/second_argument_type, but will fall back to the set of function templates that deduce the argument types from the call. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
