Spacing_spanner::prune_loose_columns: prune in-place

Spacing_spanner::prune_loose_columns: prune in-place

This saves a tiny amount of time and memory.

[Dan Eble, 2018-06-19 23:55:10]

LGTM

[benko.pal, 2018-07-10 17:10:53]

LGTM; just by looking I can't see how it can make make fail.
using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to me, but
YMMV.

[dak, 2018-07-10 17:49:33]

On 2018/07/10 17:10:53, benko.pal wrote:
> LGTM; just by looking I can't see how it can make make fail.
> using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to me, but
> YMMV.

Since the whole point is to do the operation in-place, rp[-2] may already have
been overwritten by rp[-1] in the last iteration.  It may seem cleaner to you to
use rp[-2] but it would be a rather ugly bug.  Doing things in-place is more
efficient but you have to keep track of what you are doing.

I consider it possible that mixing a const iterator with a non-const one might
be what caused the compilation error but I'd want to see the error message to be
sure.

[dak, 2018-07-10 18:09:19]

On 2018/07/10 17:49:33, dak wrote:
> On 2018/07/10 17:10:53, benko.pal wrote:
> > LGTM; just by looking I can't see how it can make make fail.
> > using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to me, but
> > YMMV.
> 
> Since the whole point is to do the operation in-place, rp[-2] may already have
> been overwritten by rp[-1] in the last iteration.  It may seem cleaner to you
to
> use rp[-2] but it would be a rather ugly bug.  Doing things in-place is more
> efficient but you have to keep track of what you are doing.
> 
> I consider it possible that mixing a const iterator with a non-const one might
> be what caused the compilation error but I'd want to see the error message to
be
> sure.

Just seen <https://stackoverflow.com/a/12662703> which indicates that as of
C++11, you can use a const_iterator for a call to erase (since the modifiability
is ensured by the object erase is called on and the const-ness of the iterator
is irrelevant) but apparently not previously.  So I guess it is my newer
compiler that made the erase call work without complaint.  I'll see how I can
make this C++08(?)-save.

[dak, 2018-07-10 18:24:39]

Cater to C++98

[dak, 2018-07-10 19:10:47]

I am stupid

[benko.pal, 2018-07-10 19:29:30]

On 2018/07/10 18:09:19, dak wrote:
> On 2018/07/10 17:49:33, dak wrote:
> > On 2018/07/10 17:10:53, benko.pal wrote:
> > > LGTM; just by looking I can't see how it can make make fail.
> > > using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to me,
but
> > > YMMV.
> > 
> > Since the whole point is to do the operation in-place, rp[-2] may already
have
> > been overwritten by rp[-1] in the last iteration.  It may seem cleaner to
you
> to
> > use rp[-2] but it would be a rather ugly bug.  Doing things in-place is more
> > efficient but you have to keep track of what you are doing.

ah yes, thanks for pointing this out!
actually this may worth some comments; I mean, documenting why looseness
decision is based only on original neighbours, not on after-pruning neighbours
(I know rp[-2] may not be the after-pruning neighbour either).  this may be
obvious, but I feel uneasy by just reading this file.

> > I consider it possible that mixing a const iterator with a non-const one
might
> > be what caused the compilation error but I'd want to see the error message
to
> > be sure.
> 
> Just seen <https://stackoverflow.com/a/12662703> which indicates that as of
> C++11, you can use a const_iterator for a call to erase (since the
modifiability
> is ensured by the object erase is called on and the const-ness of the iterator
> is irrelevant) but apparently not previously.  So I guess it is my newer
> compiler that made the erase call work without complaint.  I'll see how I can
> make this C++08(?)-save.

that was my guess too, but while I messed with git and make, you beat me :)
looks still good to me.

[dak, 2018-07-10 20:27:28]

Add a comment according to Pál's suggestion even though it turns out his
suggestion would have worked after all for even more contorted reasons