just a quick question - which maybe should have been directed at the developers list but ... would it be possible in the iterator adaptors to have an operator== defined that takes the base iterator as the right hand side? it would certainly cut down on typing and also obviate the need to create an end iterator that is only used as an 'end of container' sentinel value if it was possible it would allow us to write, for example: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), numbers + N, ostream_iterator<int>(cout, " ")); rather than: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), make_filter_iterator<is_positive_number>(numbers + N, numbers + N), ostream_iterator<int>(cout, " ")); of course i am aware that i might be missing something obvious ... ian whittley
"Witz" <witz@nildram.co.uk> writes:
just a quick question - which maybe should have been directed at the developers list but ...
would it be possible in the iterator adaptors to have an operator== defined that takes the base iterator as the right hand side? it would certainly cut down on typing and also obviate the need to create an end iterator that is only used as an 'end of container' sentinel value
if it was possible it would allow us to write, for example:
copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), numbers + N, ostream_iterator<int>(cout, " "));
rather than:
copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), make_filter_iterator<is_positive_number>(numbers + N, numbers + N), ostream_iterator<int>(cout, " "));
of course i am aware that i might be missing something obvious ...
I think you are. the signature of std::copy is: template<class InputIterator, class OutputIterator> OutputIterator copy( InputIterator first, InputIterator last, OutputIterator result); What will the compiler deduce InputIterator to be? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
if it was possible it would allow us to write, for example:
copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), numbers + N, ostream_iterator<int>(cout, " "));
rather than:
copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), make_filter_iterator<is_positive_number>(numbers + N, numbers + N), ostream_iterator<int>(cout, " "));
of course i am aware that i might be missing something obvious ...
I think you are. the signature of std::copy is:
template<class InputIterator, class OutputIterator> OutputIterator copy( InputIterator first, InputIterator last, OutputIterator result);
What will the compiler deduce InputIterator to be?
you are right of course - which is a shame. for my own use, however, i would happily rewrite the stl algorithms to allow for this usage. i often find i have issues with that area of the standard library in any case: why does binary_search not return an iterator to the item i'm searching for? why min_element, max_element when best_element, worst_element is less confusing? why no copy_if? etc. of course that could just be me :) ian whittley
From: "Victor A. Wagner Jr."
what the heck are best_element and worst_element? at least I _know_ what min and max are.
we all _know_ what min and max are - that's the problem - we have a default predicate in mind - so min_element(begin, end, greater) doesn't work as you would initially (intuitively) expect - to understand it generally requires viewing it as min_indexed_element_if_ordered_by. best and worst have the advantage of requiring a context before they can be understood - best_element(begin, end, greater) should therefore be clear to just about anybody (i would hope :) ian whittley
At Friday 2004-04-16 12:18, you wrote:
From: "Victor A. Wagner Jr."
what the heck are best_element and worst_element? at least I _know_ what min and max are.
we all _know_ what min and max are - that's the problem - we have a default predicate in mind - so min_element(begin, end, greater) doesn't work as you would initially (intuitively) expect - to understand it generally requires viewing it as min_indexed_element_if_ordered_by.
you have actually seen someone (other than yourself) write: min_element(begin, end, greater) ?? reminds me of the long gone (thankfully) unless(blah) from BCPL
best and worst have the advantage of requiring a context before they can be understood - best_element(begin, end, greater) should therefore be clear to just about anybody (i would hope :)
ian whittley
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
you have actually seen someone (other than yourself) write: min_element(begin, end, greater) ??
reminds me of the long gone (thankfully) unless(blah) from BCPL
i don't write it either - my predicated [min|max]_element functions are called [best|worst]_element - didn't i mention that? my work involves solving combinatorial optimisation problems - i don't want separate code bases for maximiation and minimisation problems - hence using generic functions. ian whittley
participants (3)
-
David Abrahams -
Victor A. Wagner Jr. -
Witz