On Saturday 23 January 2016 17:46:39 Andre Somers wrote: > On 22-1-2016 22:51, Kevin Kofler wrote: > > I'd already be happy with those that were (are, actually) already > > there. I'd rather have 10-20 common algorithms with a convenient API > > than 80+ obscure ones that force me to use iterators (especially the > > boilerplate .begin() and .end() iterators that will be used in 99+% of > > the cases – copy&paste programming sucks). > > Please note that the algorithms in STD are by no means complete. You are > stimulated to add your own that you find useful, either as > specializations or combinations of what is already there, as > implementations of known algorithms in literature or even completely new > ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent). > Stephanov has seen his original design of STL been significantly > shortened to get it through the commission; the proposal included much > more than what is in STD even now after the more recent additions. > > So, by all means, add what you deem useful. > > I certainly agree that having to write begin/end pairs for all > algorithms is not nice. It is the most general way to specify them > however, so I understand why they are like this. And it even makes sense > for some of them (like find, where you can then call find again using > the return value of the last call to get the next match). Even for sort > there certainly are use cases for a pair of iterators instead of passing > the whole container. Still, it would make perfect sense to create > versions that take a whole container. I don't even think that that is > hard to do... > > template < class Container, class Compare > > void sort ( Container container, Compare compare) > { > sort(begin(container), end(container), compare); > }; > > Something like that perhaps? Feel free to add as many as you think are > useful.
The problem is that these overloads quickly become ambiguous with existing ones. So at a minimum, you need to have a special suffix (_all).Overloading on concepts is needed to solve this properly. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development