=20 >>> void shift_right(BidirIt first, BidirIt last, unsigned int n =3D 1)=20 >>> {=20 >>> std::move_backward(first, last - n, last);=20 >>> } >>> >>> This demonstrates that while std::shift is implementable with=20 >>> std::move/std::move_backward, >>> 1) It isn't immediately clear from the code (at least to my eyes) that= =20 >>> this is a shift right, unless you are intimately familiar with=20 >>> std::move_backward. >>> 2) Different calls, either to std::move or to std::move_backward, are= =20 >>> required, depending on the shift direction. >>> >> >> If you're shifting the whole container's contents, you could use either= =20 >> of these: >> std::move(ctr.rbegin() + n, ctr.rend(), ctr.rbegin()); >> std::move_backward(ctr.begin(), ctr.end() - n, ctr.end())? >> I don't currently see the use-case for this "shift just a piece of a=20 >> container" algorithm, I mean as distinct from std::move and=20 >> std::move_backward which already exist. Do you have a use-case? >> > > The use-case would be anytime you'd want to use the code you just wrote.= =20 > When you have a range and N, and you want to do a shift N units in that= =20 > direction. > > The point of having it is one of clarification and user expectations. Yes= ,=20 > you can use `move` and `move_backward` to accomplish a shift. But conside= r=20 > the two function calls: > > //A > std::shift(rng.begin(), rng.end(), N); > > //B > auto rrng =3D std::make_reverse_range(rng); > std::move(rrng.begin() + N, rrng.end(), rrng.begin()); > > A and B both do the same thing. But it's a *lot easier* to figure out=20 > what the code is actually accomplishing from looking at A than B. > Do you have a use-case for either of these? I recall your admonition cross-thread that generally in the STL we *don't*= =20 want to operate on containers but rather on ranges (or iterator-pairs); so= =20 if I had a range that I wanted to "shift", I would first consider whether I= =20 could do something like // OLD: shift_in_place(range, n); operate_on(range.begin(),=20 range.end()); // NEW: operate_on(range.begin() + n, range.end()); That is, instead of moving the actual data, which might be slow, I'd move= =20 one or the other "endpoint" while leaving the data in place. In his reply, Dan Raviv mentioned that this is exactly the kind of thing=20 that a circular buffer does, and he's right (see proposal P0059). B gets even more obtuse confusing in a range-based world: > > //A > std::shift(rng, N); > > //B > auto rrng =3D std::make_reverse_range(rng); > std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin()); > In a range-based world, I would write this as auto output =3D input | rng::drop(n); for a "left-shift", or... okay, the "right-shift" version is messy, at=20 least in my version, because it involves concatenating ranges one of which= =20 needs to be created out of whole cloth, with n objects, each of which is in= =20 a "valid but unspecified" state. (I'd bet *money* you can't give me a=20 use-case for *that* one.) I'd still like to see a use-case for O(n) "shifting" a sequence of elements= =20 in-place (as opposed to using one of these range-based approaches, or using= =20 a circular buffer, or "shifting the endpoints"). I agree that sometimes=20 you do want to copy/move the second part of a sequence over the first part,= =20 but I would always express that in terms of "I'm std::copy'ing /=20 std::move'ing data." Expressing it as a "shift" doesn't feel natural to me= =20 in any of the (extremely rare) use-cases I've thought of. Do you have a=20 use-case? =E2=80=93Arthur --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/99d55051-ad56-4386-8a0f-9d7627b63106%40isocpp.or= g. ------=_Part_612_799264021.1499966478087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, July 12, 2017 at 6:43:11 PM UTC-7, Nicol Bol= as wrote:

On W= ednesday, July 12, 2017 at 7:47:05 PM UTC-4, Arthur O'Dwyer wrote:
On Wednesday, July 12, = 2017 at 2:53:19 AM UTC-7, d...@soundradix.com wrote:
Hi,

Would anyon= e be interested in adding std::shift to <algorithm>?=C2=A0
=
It would be similar to both:
- std::rotate, but wi= thout moving the head elements back to the tail. This would allow a more ef= ficient implementation and clearer semantics in case rotation is not needed= as well as correctness in case rotation is undesired.
- <algo= rithm>'s std::move/std::move_backward (depending on the shift direct= ion).

std::shift should probably accommodate both = left and right shifts by one of:
- giving it either begin() and e= nd(), or rbegin() and rend(), similar to how std::rotate works for both lef= t and right rotations. The advantage is compactness of the implementation.<= /div>
- allowing the shift count parameter to be either positive or neg= ative. The advantage is compactness, though it might not be clear which dir= ection is which - to be consistent with rotate, positive integers should sh= ift to the left.
- having std::shift_right and std::shif= t_left functions. The advantage is clarity when calling the methods, althou= gh the same argument could be made for having separate std::rotate_left and= std::rotate_right instead of std::rotate, which we don't have.

std::rotate is actually just a r= otation; it doesn't need "left" or "right" qualific= ation because they're 100% equivalent. Consider a classroom globe with = London in front, facing you. Now "rotate" the globe until Beijing= is in front. It doesn't matter if you rotate left or rotate right; the= outcome is exactly the same either way.
=C2=A0
Here's a sample imple= mentation of a shift to the right direction:

template<class BidirIt> void shift_right(BidirIt first, BidirIt<= /span> last, <= span style=3D"color:#008">unsigned int n = =3D 1) { =C2=A0 =C2=A0 std:= :move_backward(first, last -= n, last); } <= /div>

This demonstrates that while std::shi= ft is implementable with std::move/std::move_backward,
1) It isn&= #39;t immediately clear from the code (at least to my eyes) that this is a = shift right, unless you are intimately familiar with std::move_backward.
2) Different calls, either to std::move or to std::move_backward, a= re required, depending on the shift direction.

If you're shifting the whole container's contents, = you could use either of these:
=C2=A0 =C2=A0 std::move(ctr.rbegin= () + n, ctr.rend(), ctr.rbegin());
=C2=A0 =C2=A0 std::move_backwa= rd(ctr.begin(), ctr.end() - n, ctr.end())?
I don't curre= ntly see the use-case for this "shift just a piece of a container"= ; algorithm, I mean as distinct from std::move and std::move_backward which= already exist. Do you have a use-case?

Th= e use-case would be anytime you'd want to use the code you just wrote. = When you have a range and N, and you want to do a shift N units in that dir= ection.

The point of having it is one of clarification and user expe= ctations. Yes, you can use `move` and `move_backward` to accomplish a shift= .. But consider the two function calls:

//A
std::shift(rng.begin(), rng.end(), N);

//B
auto rrng =3D std::make_reverse_range(rng);
std::move(rrng.begin() + N, rrng.end(), rrng.begin());

=
A and B both do the same thing. But it's a lot easier to fig= ure out what the code is actually accomplishing from looking at A than B.

Do you have a use-case for e= ither of these?

I recall your admonition cross-thread that genera= lly in the STL we *don't* want to operate on containers but rather on r= anges (or iterator-pairs); so if I had a range that I wanted to "shift= ", I would first consider whether I could do something like

=C2=A0 =C2=A0 // OLD: shift_in_place(range, n); operate_on(r= ange.begin(), range.end());

=C2=A0 =C2=A0 // NEW: operate_on(rang= e.begin() + n, range.end());

That is, instead of m= oving the actual data, which might be slow, I'd move one or the other &= quot;endpoint" while leaving the data in place.

In his reply= , Dan Raviv mentioned that this is exactly the kind of thing that a circula= r buffer does, and he's right (see proposal P0059).

B gets even more obtuse confusing in a range-based w= orld:

//A std::shift(rng, N); //B auto rrng =3D std::make_reverse_range(rng); std::move(std= ::make_range(rrng.begin= + N, rrng.end()), rrng.begin());

In a range-ba= sed world, I would write this as

=C2=A0 =C2=A0 aut= o output =3D input | rng::drop(n);

for a "lef= t-shift", or... okay, the "right-shift" version is messy, at= least in my version, because it involves concatenating ranges one of which= needs to be created out of whole cloth, with n objects, each of which is i= n a "valid but unspecified" state. =C2=A0(I'd bet money you can't give me a use-case for that one.)

I'd still like to see a use-case for O(n) "shifting" a= sequence of elements in-place (as opposed to using one of these range-base= d approaches, or using a circular buffer, or "shifting the endpoints&q= uot;). =C2=A0I agree that sometimes you do want to copy/move the second par= t of a sequence over the first part, but I would always express that in ter= ms of "I'm std::copy'ing / std::move'ing data." Expre= ssing it as a "shift" doesn't feel natural to me in any of th= e (extremely rare) use-cases I've thought of. Do you have a use-case?

=E2=80=93Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/99d55051-ad56-4386-8a0f-9d7627b63106= %40isocpp.org.
------=_Part_612_799264021.1499966478087-- ------=_Part_611_508594222.1499966478086-- .