on Thu Oct 06 2011, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:
Christian Holmquist wrote:
On 5 October 2011 17:53, Stephan T. Lavavej
<stl@exchange.microsoft.com>wrote:
#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.
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 =)
Too much coffee is bad for you, so this is a good thing!
-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.
In the "meow" example above, forcing the construction of a std::string from the string literal implies a free store allocation which, in turn, generally implies a global lock. That means it can be a drag on MT performance. A library function shouldn't impose that if preventing or avoiding it is practicable.
Avoiding it is easy for the user: use the version that takes a predicate. 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 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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com