>> void shift_right(BidirIt first, BidirIt last, unsigned int n = 1) >> { >> std::move_backward(first, last - n, last); >> } >> >> This demonstrates that while std::shift is implementable with >> std::move/std::move_backward, >> 1) It isn'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, are >> required, depending on the shift direction. >> > > If you're shifting the whole container's contents, you could use either 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 > container" algorithm, I mean as distinct from std::move and > 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. When you have a range and N, and you want to do a shift N units in that direction. The point of having it is one of clarification and user expectations. 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 = 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 what the code is actually accomplishing from looking at A than B. B gets even more obtuse confusing in a range-based world: //A std::shift(rng, N); //B auto rrng = std::make_reverse_range(rng); std::move(std::make_range(rrng.begin + N, rrng.end()), rrng.begin()); -- 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 email 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/c722a201-5c9c-4ac5-a1bd-e50beb6d7860%40isocpp.org. ------=_Part_167_271704742.1499910191275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wednesday, July 12, 2017 at 7:47:05 PM UTC-4, Arthur O&= #39;Dwyer wrote:

On Wednesday, July 12, 2017 at 2:53:19 AM UTC-7, d...@soundradix.com<= /a> wrote:
Hi,
=
Would anyone be interested in adding std::shift to <algor= ithm>?=C2=A0

It would be similar to both:
=
- std::rotate, but without moving the head elements back to the tail. = This would allow a more efficient implementation and clearer semantics in c= ase rotation is not needed as well as correctness in case rotation is undes= ired.
- <algorithm>'s std::move/std::move_backward (dep= ending on the shift direction).

std::shift should = probably accommodate both left and right shifts by one of:
- givi= ng it either begin() and end(), or rbegin() and rend(), similar to how std:= :rotate works for both left and right rotations. The advantage is compactne= ss of the implementation.
- allowing the shift count parameter to= be either positive or negative. The advantage is compactness, though it mi= ght not be clear which direction is which - to be consistent with rotate, p= ositive integers should shift to the left.
- having std:= :shift_right and std::shift_left functions. The advantage is clarity when c= alling the methods, although the same argument could be made for having sep= arate std::rotate_left and std::rotate_right instead of std::rotate, which = we don't have.

std::r= otate is actually just a rotation; it doesn't need "left" or = "right" qualification because they're 100% equivalent. Consid= er a classroom globe with London in front, facing you. Now "rotate&quo= t; 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 implementation of a shift to the right direction:
<= /div>
template<class BidirIt> void shift_right(BidirIt first, BidirIt last, unsigned int n =3D 1) { =C2=A0 =C2=A0 std<= span style=3D"color:#660">::move_backward= (first<= /span>, last <= span style=3D"color:#660">- n, last); }

This demo= nstrates that while std::shift is implementable with std::move/std::move_ba= ckward,
1) It isn'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, are required, depending on the shift direction.<= /div>

If you're shifting the whol= e 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_backward(ctr.begin(), ctr.end() - n, ctr.end()= )?
I don't currently see the use-case for this "shift ju= st a piece of a container" algorithm, I mean as distinct from std::mov= e and 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. When you have a range and N, and you want to = do a shift N units in that direction.

The point of having it is one = of clarification and user expectations. Yes, you can use `move` and `move_b= ackward` 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());<=
/span>

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

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.en=
d()), rrng.begin());

--
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/c722a201-5c9c-4ac5-a1bd-e50beb6d7860= %40isocpp.org.
------=_Part_167_271704742.1499910191275-- ------=_Part_166_819055649.1499910191274-- .