Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-06 13:14:36

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_at_[hidden]>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