[function] is function_equal used?
The documentation says that comparisons require EqualityComparable, and contains_test never tests with objects that define function_equal instead of operator==. Also, there seems to be no test for boost::bind objects being put in a function<> (although there is one for lambda::bind). The reason I'm posting this is that I just switched boost::bind to implement function_equal instead of operator==, and this functionality isn't covered by our current tests. -- Peter Dimov http://www.pdimov.com
On Mar 13, 2005, at 12:28 PM, Peter Dimov wrote:
The documentation says that comparisons require EqualityComparable, and contains_test never tests with objects that define function_equal instead of operator==.
Bad documentation, no cookie. I've fixed the offending text: function_equal is used.
Also, there seems to be no test for boost::bind objects being put in a function<> (although there is one for lambda::bind).
That's because Boost.Bind never did anything strange to break Function :) The lambda::bind test is the because the overloaded address-of operator in Lambda caused breakage in function (hence the addition of addressof()).
The reason I'm posting this is that I just switched boost::bind to implement function_equal instead of operator==, and this functionality isn't covered by our current tests.
I've added more tests to cover this. Doug
Douglas Gregor wrote:
On Mar 13, 2005, at 12:28 PM, Peter Dimov wrote:
The reason I'm posting this is that I just switched boost::bind to implement function_equal instead of operator==, and this functionality isn't covered by our current tests.
I've added more tests to cover this.
This: namespace boost { bool function_equal(const ReturnIntFE& x, const ReturnIntFE& y) { return x.value == y.value; } } is the proper way to define function_equal on compilers that do not have argument dependent lookup. It will fail on conforming compilers because of two-phase lookup in templates. When ADL is supported, function_equal should be defined in the namespace of the class (ReturnIntFE in this case). This is still not the whole story. On compilers that do not implement partial function template ordering, we need to define function_equal_impl instead, if the class is a template (the rule that nontemplates beat templates will save us in the above example). This is how bind defines its function_equal, taking into account all of these factors: // function_equal #ifndef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP // put overloads in _bi, rely on ADL # ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING template<class R, class F, class L> bool function_equal( bind_t<R, F, L> const & a, bind_t<R, F, L> const & b ) { return a.compare(b); } # else template<class R, class F, class L> bool function_equal_impl( bind_t<R, F, L> const & a, bind_t<R, F, L> const & b, int ) { return a.compare(b); } # endif // #ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING #else // BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP // put overloads in boost } // namespace _bi # ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING template<class R, class F, class L> bool function_equal( _bi::bind_t<R, F, L> const & a, _bi::bind_t<R, F, L> const & b ) { return a.compare(b); } # else template<class R, class F, class L> bool function_equal_impl( _bi::bind_t<R, F, L> const & a, _bi::bind_t<R, F, L> const & b, int ) { return a.compare(b); } # endif // #ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING namespace _bi { #endif // BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP "Great", I hear you saying. ;-) Such is life in broken-compiler-land. The function_equal tests should probably be moved to their own contains_fe_test.cpp in order to not introduce "fake" regressions in contains_test.
On Mar 18, 2005, at 8:45 AM, Peter Dimov wrote:
This is how bind defines its function_equal, taking into account all of these factors: [lot's o' code] "Great", I hear you saying. ;-) Such is life in broken-compiler-land. The function_equal tests should probably be moved to their own contains_fe_test.cpp in order to not introduce "fake" regressions in contains_test.
"Great" was one of the many words I said, but of course you're right :) Doug
participants (2)
-
Douglas Gregor -
Peter Dimov