On 5 October 2011 17:53, Stephan T. Lavavej <stl@exchange.microsoft.com>wrote:
[Marshall Clow]
So, what do people prefer (and why?):
template<typename InputIterator, typename V> bool none_of_equal ( InputIterator first, InputIterator last, V const &val )
or
template<typename InputIterator, > bool none_of_equal ( InputIterator first, InputIterator last, iterator_traits<InputIterator>::value_type const &val )
In the first case, I think there's (possible) conversion from V to iterator_traits<InputIterator>::value_type each time through the loop. In the second case, there is not.
#1 is better. It follows the STL's conventions (e.g. look at std::find()) and permits heterogeneous comparisons.
Consider vector<string> and val being "meow". string is directly comparable to const char *, without any conversions or temporaries.
Even better, consider vector<const char *> and val being a string. Here, the element type is still directly comparable to val's type, but val's type is not implicitly convertible to the element type.
The never ending reference to std::string vs const char* performance thing. I'm simply amazed about the simplicity of other developers performance issues, if this was the main bottleneck I would ever deal with I could have more time drinking coffee =) -IF- such a case would show up in a profiler, I think it's only fair to let the developer optimize his scenario with some custom code, that to open up this can of worms for everyone else. Honestly I hadn't considered how dangerous std::find etc is until a discussion came up related to clamp() in other thread. There is a std::function call find_if ( http://www.sgi.com/tech/stl/find_if.html), let it handle the odd-ball of comparing unrelated types. I understand the rational for not changing the c++ standard, but since Boost.Algorithms is a new library with no requirements on backward compatibility, let's not redo the same mistake. - Christian