Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2011-10-06 12:15:53

On 5 October 2011 17:53, Stephan T. Lavavej <stl_at_[hidden]>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