boost/test/detail/algorithm.hpp: request for promotion and/or fast review
Hi, I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory): template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 ); template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred ); template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ) template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 ); template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred ); Implementation together with doxigen docs is here: http://tinyurl.com/35pfj Test is here: http://tinyurl.com/yvlgu If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace. Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I added several algorithms that extent STL algorithms set....
I think they belonh tp boost::algorithm. Wouldn't it make sense to add overloads that use std::pair<iter, iter>?, e.g: template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( const std::pair<InputIter1, InputIter1>& seq1, const std::pair<InputIter2, InputIter2>& seq2 ) /Pavel
I added several algorithms that extent STL algorithms set....
I think they belong to boost::algorithm.
Wouldn't it make sense to add overloads that use std::pair<iter, iter>?, e.g:
template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( const std::pair<InputIter1, InputIter1>& seq1, const std::pair<InputIter2, InputIter2>& seq2 )
I don't think so. current STL doesn't have it. In a future I would rather prefer to have "container" version of all STL algorithms (using recently accepter container traits) and std::pair will be accepted automatically. Gennadiy.
I'm w/ Pavel on this one. After reading my first book on the STL (Josuttis) I was struck that although "ranges" are used all over the place, nobody apparently ever formalized the concept into an actual type. std::pair<iter, iter> certainly seems like something we'd like to have actualized. I understand that it's syntactic sugar, but given some more sugar e.g. (approximation only) template<class container> pair<typename container::iterator, typename container::iterator> all_of(container const& who) {return make_pair(who.begin(), who.end());} then you could write: vector<blah> x; . . . sort(all_of(x)); // instead of sort(x.begin(), x.end()); and such this presumes, of course, that we add the similar syntactic sugar overloads to all of the algorithms At Sunday 2004-05-23 07:41, you wrote:
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I added several algorithms that extent STL algorithms set....
I think they belonh tp boost::algorithm.
Wouldn't it make sense to add overloads that use std::pair<iter, iter>?, e.g:
template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( const std::pair<InputIter1, InputIter1>& seq1, const std::pair<InputIter2, InputIter2>& seq2 )
/Pavel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Why don't we provide container versions of all stl algorithms: template<typename C,typename P> inline for_each( C const& c, P pred) // or non const ref?? { // unwrap here used to allow by_ref( c ) usage for mutable predicates std::for_each( begin( unwrap( c ) ), end( unwrap( c ) ), P ); } Gennadiy.
I really think we'd be better off creating a new templated class, like std::pair<> but with both types needing to be the same and iterators. We could make a constructor for such a class using your model below) and we'd get what you want AND we'd get a concrete "range" object at the same time. At Sunday 2004-05-23 21:36, you wrote:
Why don't we provide container versions of all stl algorithms:
template<typename C,typename P> inline for_each( C const& c, P pred) // or non const ref?? { // unwrap here used to allow by_ref( c ) usage for mutable predicates std::for_each( begin( unwrap( c ) ), end( unwrap( c ) ), P ); }
Gennadiy.
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Gennadiy Rozental wrote:
Why don't we provide container versions of all stl algorithms:
template<typename C,typename P> inline for_each( C const& c, P pred) // or non const ref?? { // unwrap here used to allow by_ref( c ) usage for mutable predicates std::for_each( begin( unwrap( c ) ), end( unwrap( c ) ), P ); }
This depends who do you mean by "we" ;-) There's a bunch of container algorithms in the sandbox: http://tinyurl.com/yv6q3 and I use them quite a lot. - Volodya
I couldn't find the doxygen docs At Sunday 2004-05-23 03:06, you wrote:
Hi,
I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory):
template <class InputIter1, class InputIter2> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2 );
template <class InputIter1, class InputIter2, class Predicate> inline std::pair<InputIter1, InputIter2> mismatch( InputIter1 first1, InputIter1 last1, InputIter2 first2, InputIter2 last2, Predicate pred );
template<class ForwardIterator1, class ForwardIterator2> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 );
template<class ForwardIterator1, class ForwardIterator2, class Predicate> inline ForwardIterator1 find_first_not_of( ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred );
template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 )
template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred );
template<class BidirectionalIterator1, class ForwardIterator2> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2 );
template<class BidirectionalIterator1, class ForwardIterator2, class Predicate> inline BidirectionalIterator1 find_last_not_of( BidirectionalIterator1 first1, BidirectionalIterator1 last1, ForwardIterator2 first2, ForwardIterator2 last2, Predicate pred );
Implementation together with doxigen docs is here:
Test is here:
If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace.
Gennadiy.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
I couldn't find the doxygen docs
Check the link below. Or do you mean separate file?
Implementation together with doxigen docs is here:
Gennadiy.
I guess I misread what you said. I expected to find some (at least) .html files instead of a doxygenated source file. I can easily enough run doxygen on it myself (and will) At Sunday 2004-05-23 11:02, you wrote:
I couldn't find the doxygen docs
Check the link below. Or do you mean separate file?
Implementation together with doxigen docs is here:
Gennadiy.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
I couldn't find the doxygen docs At Sunday 2004-05-23 03:06, you wrote:
Hi,
<snip entire quoted posting> Please limit the length of quoted material in your posts. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms. Here is the list (I hope name and spec is self -explanatory):
Why are they inlined? None are small enough to justify that. Other than that, they look highly useful.
If we don't find this header eligible for review I would like to ask then for permision to at least put this algorithm in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace.
Isn't a namespace alias sufficient to solve that problem? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Thanks Rob for bringing the thread back to life, I missed it somehow. On May 23, 2004, at 6:06 AM, Gennadiy Rozental wrote:
I added several algorithms that extent STL algorithms set. I use them in my Boost.Test development. But since they seems to be generic and IMO should be present in STL I propose to push them in boost/algorithm.hpp (or under boost/algorithm). I remember there was a discussion already about these algorithms.
Yes, I like them. I'm sure the rationale has been discussed, and if you make this into a mini-boost library, you'll have to add this to a page. My 2 cents (sorry if this rehashes): 1. The reason std::mismatch does not have a last2 argument is for efficiency, but it presupposes knowing the range length (or at least knowing which one is longer, in order to pass it as first argument). At the cost of one extra comparison per element, you get rid of that requirement and of the occasional reordering of the arguments. 2. One can get find_first_not_of by using find_first_of with std::not2(pred), but your version is more readable and also cuts down on the includes. 3. BTW, since you're using std::bind1st, you should include <functional> With two small web pages of documentation (one for mismatch, and one for find_first_of variants), in the manner of the other boost libraries (including rationale, etc.) I'd heartily support the addition to boost/algorithm/ Now, I'd rather this isn't called a Boost.algorithms library, because there are more that will come in the same vein (already minmax and minmax_element are also separate headers and fill in the same purpose: new algorithms to add to the STL; also I sorely miss is_sorted which was removed from the standard). I'd rather have them in separate headers mismatch.hpp and find_first_of.hpp (since those are extensions of). We can always have a single header algorithm.hpp that includes all those and more as they are submitted. Finally, these little algorithms are barely a library. There was an idea of mini-reviews tossed around. This wouldn't include range / container traits (as Thorsten Ottosen or John Torjo are doing) since it's a much bigger scope, but for one or two functions, a single header, it seems an overkill to have a review. Can we have an Algorithms Review Manager under the Review Manager (as he see fits to forward requests) for the subspace boost::algorithm? I'd volunteer as one if no one else. My two cents, -- Herve'
Hervé Brönnimann <hbr@poly.edu> writes:
There was an idea of mini-reviews tossed around.
Maybe our new review wizard can kick that process off? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (7)
-
David Abrahams -
Gennadiy Rozental -
Hervé Brönnimann -
Pavel Vozenilek -
Rob Stewart -
Victor A. Wagner Jr. -
Vladimir Prus