[range] iterator_range operators are too greedy
Hi, iterator_range operators are defined like this: template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); } These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible. Gennadiy
On Thu, Nov 8, 2012 at 9:35 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Hi,
iterator_range operators are defined like this:
template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); }
These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible.
Is this related to https://svn.boost.org/trac/boost/ticket/6715? Sadly not a single response from the Range maintainers. -- Olaf
On 08-11-2012 11:11, Olaf van der Spek wrote:
On Thu, Nov 8, 2012 at 9:35 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Hi,
iterator_range operators are defined like this:
template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); }
These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible.
Is this related to https://svn.boost.org/trac/boost/ticket/6715? Sadly not a single response from the Range maintainers.
It seems to be related. What would the enable_if expression look like? -Thorsten
On 08/11/12 13:12, Thorsten Ottosen wrote:
On 08-11-2012 11:11, Olaf van der Spek wrote:
On Thu, Nov 8, 2012 at 9:35 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote: Is this related to https://svn.boost.org/trac/boost/ticket/6715? Sadly not a single response from the Range maintainers.
It seems to be related.
What would the enable_if expression look like?
Replacing all overalods of operator== by something like template<class A0, class A1> typename enable_if< mpl::or_< is_base_of<iterator_range_base, A0>, is_base_of<iterator_range_base, A1> > , bool
::type operator==(A0 const& a0, A1 const& a1) { return boost::equal(a0, a1); }
should allow to fix the bug above.
On Thu, Nov 8, 2012 at 4:48 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 08/11/12 13:12, Thorsten Ottosen wrote:
On 08-11-2012 11:11, Olaf van der Spek wrote:
On Thu, Nov 8, 2012 at 9:35 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote: Is this related to https://svn.boost.org/trac/**boost/ticket/6715<https://svn.boost.org/trac/boost/ticket/6715> ? Sadly not a single response from the Range maintainers.
It seems to be related.
What would the enable_if expression look like?
Replacing all overalods of operator== by something like
template<class A0, class A1> typename enable_if< mpl::or_< is_base_of<iterator_range_**base, A0>, is_base_of<iterator_range_**base, A1> > , bool
::type operator==(A0 const& a0, A1 const& a1) { return boost::equal(a0, a1); }
should allow to fix the bug above.
Though an improvement, that's still not very constrained and I doubt it will address Gennadiy's issue. - Jeff
On 08/11/12 14:53, Jeffrey Lee Hellrung, Jr. wrote:
Replacing all overalods of operator== by something like
template<class A0, class A1> typename enable_if< mpl::or_< is_base_of<iterator_range_**base, A0>, is_base_of<iterator_range_**base, A1> > , bool
::type operator==(A0 const& a0, A1 const& a1) { return boost::equal(a0, a1); }
should allow to fix the bug above.
Though an improvement, that's still not very constrained and I doubt it will address Gennadiy's issue.
It would be his responsability to make it so that any additional operator== overload he is a better match...
On 8 Nov 2012 10:13, "Olaf van der Spek" <ml@vdspek.org> wrote:
On Thu, Nov 8, 2012 at 9:35 AM, Gennadiy Rozental <rogeeff@gmail.com>
wrote:
Hi,
iterator_range operators are defined like this:
template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); }
These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible.
Is this related to https://svn.boost.org/trac/boost/ticket/6715? Sadly not a single response from the Range maintainers.
Sadly the maintainer has been extremely busy. I have acknowledged that tickets have been waiting longer than I would have liked. It is something I will address but has never appeared to be anything more than a minor inconvenience previously. In the new year I will be able to devote more time to improving Boost.Range. this will include bringing in new code submitted by others that I have been reviewing for a little while. I am listening to people and ensuring that anything major is addressed. I am also working toward a schedule that will deliver more for Boost. I am also disappointed by the amount of time that I have had available for this. The tickets for Boost.Range are not being ignored and there is a credible plan to hasten progress.
-- Olaf
Neil Groves
On Tue, Nov 13, 2012 at 11:08 PM, Neil Groves <neil@grovescomputing.com> wrote:
Is this related to https://svn.boost.org/trac/boost/ticket/6715? Sadly not a single response from the Range maintainers.
Sadly the maintainer has been extremely busy. I have acknowledged that tickets have been waiting longer than I would have liked. It is something I will address but has never appeared to be anything more than a minor inconvenience previously. In the new year I will be able to devote more time to improving Boost.Range. this will include bringing in new code submitted by others that I have been reviewing for a little while.
I am listening to people and ensuring that anything major is addressed. I am also working toward a schedule that will deliver more for Boost.
I am also disappointed by the amount of time that I have had available for this.
The tickets for Boost.Range are not being ignored and there is a credible plan to hasten progress.
Hi Neil, What can we do to help you? -- Olaf
On 26-11-2012 19:36, Olaf van der Spek wrote:
The tickets for Boost.Range are not being ignored and there is a credible plan to hasten progress.
Hi Neil,
What can we do to help you?
I don't know the procedure for this, but I would like to see more people being able to apply patches we basically all agree should be done. -Thorsten
I am also disappointed by the amount of time that I have had available for this.
The tickets for Boost.Range are not being ignored and there is a credible plan to hasten progress.
Hi Neil,
What can we do to help you?
Anyone with write permissions may apply patches to Boost.Range. I'm happy for this to go ahead given that all active tickets have been discussed. All help is appreciated.
-- Olaf
Thanks, Neil Groves
On Thu, Nov 8, 2012 at 12:35 AM, Gennadiy Rozental <rogeeff@gmail.com>wrote:
Hi,
iterator_range operators are defined like this:
template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); }
These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible.
Is your type a range? How does its semantics differ from the operator== above? Presumably if you want to specifically address boost::iterator_range, then template< class I > inline bool operator==(my_type, iterator_range<I>); should be a preferable overload. - Jeff
Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> writes:
Is your type a range?
No.
How does its semantics differ from the operator== above?
I am building an expression template structure to delay operator== evaluation.
Presumably if you want to specifically address boost::iterator_range, then
template< class I > inline bool operator==(my_type, iterator_range<I>);
should be a preferable overload.
Unfortunately it is not. I am getting ambiguity errors. Gennadiy
On Thu, Nov 8, 2012 at 2:17 PM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> writes:
Is your type a range?
No.
How does its semantics differ from the operator== above?
I am building an expression template structure to delay operator== evaluation.
Sounds like hackery :)
Presumably if you want to specifically address boost::iterator_range, then
template< class I > inline bool operator==(my_type, iterator_range<I>);
should be a preferable overload.
Unfortunately it is not. I am getting ambiguity errors.
Works for me (MSVC9): #include <boost/range/iterator_range.hpp> struct my_type { }; template< class I > inline bool operator==(my_type, boost::iterator_range<I>) { return false; } int main(int argc, char* argv[]) { my_type x; boost::iterator_range< int* > i; x == i; return 0; } - Jeff
participants (6)
-
Gennadiy Rozental -
Jeffrey Lee Hellrung, Jr. -
Mathias Gaunard -
Neil Groves -
Olaf van der Spek -
Thorsten Ottosen