Re: [lmi] When should std::distance (not) be used?

[Greg Chicares]

On 2017-01-20 14:42, Vadim Zeitlin wrote:
> On Fri, 20 Jan 2017 10:21:17 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> lmi uses std::distance() only twice. Here:
> GC> 
> GC> template<typename InputIterator, typename T>
> GC> bool each_equal(InputIterator first, InputIterator last, T const& t)
> GC> {
> GC>     return std::distance(first, last) == std::count(first, last, t);
> GC> }
> GC> 
> GC> it's unavoidable because we have no container, only iterators.
> 
>  Annoyingly, there is exactly one case in which we need to use iterators
> here instead of passing the entire container as could be done for the 15
> other uses of this function but it doesn't look like we can get rid of that
> one (in custom_io_0.cpp).

That example shows how useful iterators can be in the general case,
which is rather uncommon. But I think the annoyance can be removed
with an overload for whole containers, which I've already pushed.
Ideally we'd restrict it to valid range-expressions, but I guess we
have to wait for Concepts to be standardized.

Let me ask a vim question. I'm changing lines like this:
    if(!each_equal(NewLoanRealized_.begin(), NewLoanRealized_.end(), 0.0))
to
    if(!each_equal(NewLoanRealized_, 0.0))
in this fashion:

 - '*' under each_equal [actually I used 'vim --cmd "vim each_equal *.?pp"]
 - 'n' to go to a line that needs changing, e.g., the one above
 - '3el' to go to the end of the first "NewLoanRealized_"
 - '2d/,' and Enter

That works well, but
 - '.' recalls only '2d/,' rather than '3el2d/,' and
 - 'd/' replaces the current search item "each_equal" with ","
so it's laborious to repeat the series of commands.

So instead of '2d/' I try 'v2f,hd', which doesn't spoil my '*' search.
Well, better, 'v2t,d' so I don't need the 'h'. I can recall that with
'.', but it doesn't include '3el'.

Is this something I should record? I.e.:
  qk3elv2t,dq
Now I can 'n' and '@k' (and '@@' subsequently).

Have I overlooked a simpler way?

>  Also, this is slightly off topic, but this implementation of each_equal()
> looks very strange to me because it doesn't "short circuit": we still loop
> until "last" inside std::count() even if the very first element is
> different from "t", which is clearly suboptimal -- but, of course, this
> pessimization is completely unnoticeable for small containers.

Fixed. Thanks.