220 33428 <3e77c029-bc79-424c-bdad-eba28ec10cdb@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Dan Raviv Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [idea for proposal] Adding std::shift to Date: Fri, 28 Jul 2017 11:43:10 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: <3e77c029-bc79-424c-bdad-eba28ec10cdb@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2136_819303541.1501267390087" X-Trace: blaine.gmane.org 1501267394 21583 195.159.176.226 (28 Jul 2017 18:43:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Jul 2017 18:43:14 +0000 (UTC) Cc: dan@soundradix.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC5YJREBWAGRBPUL53FQKGQEISTJ7KA@isocpp.org Fri Jul 28 20:43:10 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dbAE7-0005Cf-0T for gclcip-std-proposals@m.gmane.org; Fri, 28 Jul 2017 20:43:08 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id k190sf85188090pge.9 for ; Fri, 28 Jul 2017 11:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=31IFXrNmiUED2wu+UGYmZ6KG4WfRi5eQlM80peXDW+I=; b=xq9h9UuaIPtySDv48yMWLT2VyxW2czPFHVaLVPwqzxIHJJ23UD8SrGJ2iFUJH0WlJ3 GCc2TNBYODFWlrHFtKhTEcDqmhDYM79yHZO63MnerfMmsPM1B2XVwIUJDJI+damjR/ti 2HHgLi6qdtE/0GyQViUCsrHhQWfSPiA3WBH5528wsxRsbkE+4RoVAAaF4m7dMYoXxxO5 MCpzb2LUqJ5qVPBLzeTAhzkJ5nxPei825E8v3WBvG0DGJBjH5bQviWHjXVGoF0TWz/6i aeKduYmI/YRqkHNPZMiNqvxGS291QNxp1OHYvnAcl6jwFSBozqaYOB9S9YL8tDznU1eH gkaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=31IFXrNmiUED2wu+UGYmZ6KG4WfRi5eQlM80peXDW+I=; b=l1gDdI9KugQHyoLtEIn4F6tkeObOKTBRX5EYSXYnzrWwAgHZkxAydOawvcXhgR5NEJ V5nPffiLHD4dhIj32GE6+fK/e0F1QZTBe5TcUkSSz17TSaJLdP150QC4sFi8/+iKi3a1 68CNwcKAK9+ZuuC/8WiTFpKZvKRxYxmif4K0w/weGycpqNbyz1NC3qteIlmnfWSF+oiF 3+Ud+2TDz8lTWFjbNaC9VREFnYmVMtclTzKNOHPcXguE0TB1/7Kl6acRlF6tKGWem9fD 9s0o7O9tm48cr/lggbNzQtwFMiBa3VVzWrjpslW40l1JGNGA+dPHqkfNddKemrfHIpjv xFZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=31IFXrNmiUED2wu+UGYmZ6KG4WfRi5eQlM80peXDW+I=; b=NZDPdySz2zXX3mPzeX7+7PdqnFNTP6cD/zrEoZFMCJjwI2c78cb/0W0T78+74y8+xE bP6XYQp6/R8tSN0ajpfqNDuMPdBa629sdok87MMsROaYU2wK1Vo1nMMoqMm0lfpASVCe 1JJN51RlprmBGIozbqDgfTKK3Y2aJvaCh96Am09370WL02kglsNxtwVqtTDxWAISv2Eb qRDiw5rBQV2oOrmKK5nc3D/vfp2NhgCrixPqPshXBhq23H1OicxTfIbUkKpjnV4+yn5p SSEp4m+Eiy1m1cRWbwb3KpWRlu2iTmSkOZqwJGWcGT6RKPzta46dFHTuhUsix/InWLB0 l7DA== X-Gm-Message-State: AIVw112Xdi5omdMhjpk6mG7SyTYoTLdsRp5+HYH9DG9Y+j8CWv/8GQUB mFptaAyokpvmPDgK X-Received: by 10.99.63.68 with SMTP id m65mr601541pga.13.1501267392410; Fri, 28 Jul 2017 11:43:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.6.25 with SMTP id 25ls4870919iog.13.gmail; Fri, 28 Jul 2017 11:43:10 -0700 (PDT) X-Received: by 10.31.164.205 with SMTP id n196mr44693vke.22.1501267390704; Fri, 28 Jul 2017 11:43:10 -0700 (PDT) In-Reply-To: X-Original-Sender: dan.raviv@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:33428 Archived-At: ------=_Part_2136_819303541.1501267390087 Content-Type: multipart/alternative; boundary="----=_Part_2137_1779809544.1501267390087" ------=_Part_2137_1779809544.1501267390087 Content-Type: text/plain; charset="UTF-8" Does anyone know if there was a specific motivation for adding std::move_backward() to ? It seems that using std::move() with rbegin(),rend() iterators (for the basic use case) would have the same effect. On Wednesday, July 12, 2017 at 12:53:19 PM UTC+3, d...@soundradix.com wrote: > > Hi, > > Would anyone be interested in adding std::shift to ? > > 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 case > rotation is not needed as well as correctness in case rotation is undesired. > - 's std::move/std::move_backward (depending on the shift > direction). > > std::shift should probably accommodate both left and right shifts by one > of: > - giving it either begin() and end(), or rbegin() and rend(), similar to > how std::rotate works for both left and right rotations. The advantage is > compactness of the implementation. > - allowing the shift count parameter to be either positive or negative. > The advantage is compactness, though it might not be clear which direction > is which - to be consistent with rotate, positive integers should shift to > the left. > - having std::shift_right and std::shift_left functions. The advantage is > clarity when calling the methods, although 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. > > Here's a sample implementation of a shift to the right direction: > > template > 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. > > So, implementing std::shift would allow writing more readable code. > > Thanks, > Dan > -- 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/3e77c029-bc79-424c-bdad-eba28ec10cdb%40isocpp.org. ------=_Part_2137_1779809544.1501267390087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does anyone know if there was a specific motivation for ad= ding std::move_backward() to <algorithm>? It seems that using std::mo= ve() with rbegin(),rend() iterators (for the basic use case) would have the= same effect.

On Wednesday, July 12, 2017 at 12:53:19 PM UTC+3, d...= @soundradix.com wrote:
Hi,

Would anyone be interested in adding std::s= hift to <algorithm>?=C2=A0

It would be simil= ar to both:
- std::rotate, but without moving the head elements b= ack to the tail. This would allow a more efficient implementation and clear= er semantics in case rotation is not needed as well as correctness in case = rotation is undesired.
- <algorithm>'s std::move/std::m= ove_backward (depending on the shift direction).

s= td::shift should probably accommodate both left and right shifts by one of:=
- giving it either begin() and end(), or rbegin() and rend(), si= milar to how std::rotate works for both left and right rotations. The advan= tage is compactness of the implementation.
- allowing the shift c= ount parameter to be either positive or negative. The advantage is compactn= ess, though it might not be clear which direction is which - to be consiste= nt with rotate, positive integers should shift to the left.
<= div>- having std::shift_right and std::shift_left functions. The advantage = is clarity when calling the methods, although the same argument could be ma= de for having separate std::rotate_left and std::rotate_right instead of st= d::rotate, which we don't have.

Here'= ;s a sample implementation of a shift to the right direction:

template<class BidirIt<= /span>> void s= hift_right(BidirIt first, BidirIt last, unsigned int n =3D 1)
{
=C2=A0 =C2=A0 std::move_backward(first, last - n, last);
}

This demonstrates th= at 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.
<= br>
So, implementing std::shift would allow writing more readable= code.

Thanks,
Dan

--
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/3e77c029-bc79-424c-bdad-eba28ec10cdb= %40isocpp.org.
------=_Part_2137_1779809544.1501267390087-- ------=_Part_2136_819303541.1501267390087-- .