Re: [boost] Boost.Algorithm design question

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

>
>
>>>
>> Even better, don't use vector<const char*>. What o you need that for?
>>
>
> Here's a real motivating example where I want to use vector<const char*>.
>  I have a large file containing null-terminated strings which I memory map.
>  After opening the file, I construct some sort of index of those strings in
> a sorted vector.  Then I search for things using std::equal_range,
> std::lower_bound, or similar.
>

All those algorithms comes in a version that accepts a predicate, so you
would still be able to do your optimization..
And it would be clear to anyone who's reading the code what your intention
is (to avoid copies), it's simply not a 'coincidence' that there happened to
be an overload that matched your types.
For clarity and maintenance, I prefer to speak out clearly in code the
intention. If it becomes to boilerplate-ly kind of thing, wrap it up in an
own algorithm.

>
> The important thing is that for efficiency the algorithms mustn't create
> temporary strings; they must compare the const char* with the string that
> I'm searching for directly.  std::string provides operator overloads to do
> this.  I want the algorithms to use those heterogeneous comparisons.
>

I understand the first part about not creating temporaries, but not why you
want to use those heterogeneous comparisons. If it's a performance concern,
I would prefer being in control of that explicitly. If you're unlucky while
working with the code at some point in the future and happen to introduce an
implicit copy, everything will compile and run but your speed will be not
what you expected. If you're lucky it will crash and can be debugged early
on

>
> Dave Abrahams has said a couple of times that he doesn't even know what it
> means to try to do this.  This baffles me, but I trust that there is some
> validity in his argument.  But it does lead me to the point that I made in
> my review, and my answer to Marshall's question at the start of this thread:
> I don't want Boost to waste time on either of those none_of_equal
> implementations.  We are all capable of writing our own 4-line none_of_equal
> implementations that do precisely what we want them to do.  Why argue about
> which is the "one true way" to do it, when we can all have whichever one we
> prefer?  Instead, let's spend time on things where the implementation is
> more than 4 lines long - like a variant of std::list with O(1) splice!
>

If we can't get the simple ones right, there's not a  healthy ground to base
more complicated algorithms on.

Also, I don't want to write those 4 lines of code which is potentially
dangerous, simply because I wasn't aware of the implications. If I can read
in some boost rationale like 'this is how it should be done and why' (many
Boost libraries takes this higher moral ground, which I appreciate), then
I've learned something.

>
>
> Regards,  Phil.
>
>
>
cheers,
Christian

>
>