
Boost : 
Subject: Re: [boost] Boost.Algorithm design question
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 20111006 14:05:07
Dave Abrahams wrote:
>
> I don't think you can evaluate these choices just by looking at the
> implementations. Before anyone else votes option 1, I'd like to see
>
Well, I'm not so sure I like option 1 anymore... if option 1 was an
oversight in STL then there is no sense in perpetuating the specification
error in Boost.Algorithm (perhaps Boost.Algorithm should then go with option
2 and explain the rationale of why it's different than what STL does for
example with std::find).
> somebody write the description of the algorithm, including the concept
> requirements. With option 2, we know that == has to be an equivalence
> relation. The semantics in option 1 are a lot fuzzier.
>
Good point! I'll try to start :)
template< typename Iter, typename Val >
requires
InputIterator<Iter>,
EqualityComparable<iterator_traits<Iter>::value_type, Val>
bool none_of_equal ( Iter first, Iter last, Val const& val ) ; // option 1a
template< typename Iter >
requires
InputIterator<Iter>,
EqualityComparable<iterator_traits<Iter>::value_type>
bool none_of_equal ( Iter first, Iter last,
iterator_traits<Iter>::value_type const& value ) ; // option 2
Essentially, I'd think option 1 requires operator== that satisfies
has_equal_to<iterator_traits<Iter>::value_type, Val> while option 2
requires operator== that satisfies
has_equal_to<iterator_traits<Iter>::value_type>.
The alternative would be for option 1 to require instead:
template< typename Iter, typename Val >
requires
InputIterator<Iter>,
EqualityComparable<iterator_traits<Iter>::value_type>,
Convertible<Val, iterator_traits<Iter>::value_type>
bool none_of_equal ( Iter first, Iter last, Val const& val ) ; // option 1b
What do you think?
Thanks,
Lorenzo
 View this message in context: http://boost.2283326.n4.nabble.com/BoostAlgorithmdesignquestiontp3876424p3879381.html Sent from the Boost  Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk