220 17125 <44e3fa7b-3c4c-44b0-9feb-2e0d19bf820e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vlad from Moscow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Definition of std::is_sorted for iterators of the input iterator category Date: Fri, 20 Mar 2015 22:14:47 -0700 (PDT) Lines: 136 Approved: news@gmane.org Message-ID: <44e3fa7b-3c4c-44b0-9feb-2e0d19bf820e@isocpp.org> References: <29db7c40-6e09-42dd-8133-1ecb5723f005@isocpp.org> <23ACE1F6-A65D-4C22-A745-E57526ABBA0A@gmail.com> <4eae9fd4-6efd-4915-946d-0b6200401e66@isocpp.org> <246351cb-ecdf-4957-ab4a-4a6995960d33@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1463_2030033701.1426914887517" X-Trace: ger.gmane.org 1427141678 5575 80.91.229.3 (23 Mar 2015 20:14:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 20:14:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXLLRHD7IDRBEPIYGUAKGQEAC3VK4Q@isocpp.org Mon Mar 23 21:14:34 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f70.google.com ([209.85.192.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ya8ji-0004uW-Qt for gclcip-std-proposals@m.gmane.org; Mon, 23 Mar 2015 21:14:10 +0100 Original-Received: by qgea108 with SMTP id a108sf165814333qge.1 for ; Mon, 23 Mar 2015 13:14:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=5e+w+l6442+DQYdt/kYub3pPMg/AVLHjUkUX3BYaMvQ=; b=XbAj3HTPpnW6N4flpWxunX6/dBOHLhvN9mt25VJ3uiuWnGouAz+II0XpGj6Incdnul h3gsByrYoaMem3pp4lXi6mA7bR1w2GINEHUEyBK3RKTLQjAGA/bfL0S5tBHce7X+kUKy kyDpzWHREoK3CBA2yO7WuFVddSaHgINCwC5YR9Z3aJTiOUIvgXTiHcHP5NIXKkRRX3Vd WlLIzcih5uXASNYPvktqdvqgVj0RPHWLNfkrwZLfJRTE9paDXTPAt2/XgBxOh/nW6s72 wocFEiKpenAWmcYa9HQMOnQdDtpKRDatnWKRrljTK5rWtxU5s9q+mpoLiEhX1Et6mSwC u7Qg== X-Gm-Message-State: ALoCoQkuj6mmEgwJ1phi7eorTwJyCZ0UkjhRv+JZhfbFNEIU30d/Vox3bgMh3JNiALhjWRprENXV X-Received: by 10.140.147.130 with SMTP id 124mr1149689qht.8.1427141649761; Mon, 23 Mar 2015 13:14:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.98 with SMTP id a95ls1991746ioj.86.gmail; Mon, 23 Mar 2015 13:14:09 -0700 (PDT) X-Received: by 10.66.119.174 with SMTP id kv14mr1052966pab.21.1427141649182; Mon, 23 Mar 2015 13:14:09 -0700 (PDT) Original-Received: by 10.50.55.66 with SMTP id q2msigp; Fri, 20 Mar 2015 22:14:48 -0700 (PDT) X-Received: by 10.182.142.2 with SMTP id rs2mr708896obb.41.1426914888145; Fri, 20 Mar 2015 22:14:48 -0700 (PDT) In-Reply-To: <246351cb-ecdf-4957-ab4a-4a6995960d33@isocpp.org> X-Original-Sender: vlad.moscow@mail.ru 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:17125 Archived-At: ------=_Part_1463_2030033701.1426914887517 Content-Type: multipart/alternative; boundary="----=_Part_1464_1703712818.1426914887517" ------=_Part_1464_1703712818.1426914887517 Content-Type: text/plain; charset=UTF-8 And I said the same.:) It is just a polymorphism and function overloading. But it provides more possibilities and covers more use cases. The example I showed is enough interesting. Of course the algorithm is less efficient for input iterators than for forward iterators. Nevertheless it is more efficient than using some intermediate container that only to check whether a sequence is sorted. And it will not be suprising for a programmer. The programmer knows very well why he prefered to use the algorithm with input iterators instead of some container and the algorithm with forward iterators. The choice of the programmer depends on the task and its context. On Thursday, March 19, 2015 at 2:18:17 AM UTC+3, T. C. wrote: > There is precedent for having different requirements on the value type > depending on iterator category. unique_copy, for example ( > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2439). Both > unique_copy and adjacent_difference support InputIterators, even though > both need to access two elements at once. > > With two implementations and tag dispatching, implementing the proposed > change shouldn't affect the behavior or requirements for forward iterators > or stronger; this would be a pure extension. > > On Wednesday, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote: >> >> On 18 March 2015 at 01:44, Vlad from Moscow wrote: >> >>> David, your remark can be reflected in the description of the algorithm >>> in the requirements. >>> >> >> That wouldn't be a remark; copyable (and whether or not you need both >> CopyConstructible and CopyAssignable) would be a requirement. This would >> also mean that the algorithm could throw. >> >> Given the above surprising behavior (plus the performance difference >> between using InputIterators and ForwardIterators), such a proposal is >> unlikely to go anywhere. IMNSHO this is a solution in search of a problem. >> -- >> Nevin ":-)" Liber (847) 691-1404 >> > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1464_1703712818.1426914887517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And I said the same.:)

It i= s just a polymorphism and function overloading. But it provides more p= ossibilities and covers more use cases. The example I showed is enough= interesting.

Of course the algorithm is less effi= cient for input iterators than for forward iterators. Nevertheless it is mo= re efficient than using some intermediate container that only to check= whether a sequence is sorted. And it will not be suprising for a programme= r. The programmer knows very well why he prefered to use the algorithm with= input iterators instead of some container and the algorithm with forward i= terators. The choice of the programmer depends on the task and its context.=

On Thursday, March 19, 2015 at 2:18:17 AM UTC+3, T. C. wrote:
=
There is precedent for having= different requirements on the value type depending on iterator category.&n= bsp;unique_copy, for example (= http://www.open-std.org/jtc1/sc22/wg21/docs/lwg= -active.html#2439). Both unique_copy and adjacent_difference support = InputIterators, even though both need to access two elements at once.
<= br>
With two implementations and tag dispatching, implementing th= e proposed change shouldn't affect the behavior or requirements for forward= iterators or stronger; this would be a pure extension.

On Wednesda= y, March 18, 2015 at 11:21:24 AM UTC-4, Nevin ":-)" Liber wrote:
On 18 March 2015 at 01:44, Vlad from Mos= cow <vlad....@mail.ru> wrote:
<= div dir=3D"ltr">David, your remark can be reflected in the description of t= he algorithm in the requirements.

That wouldn't be a remark; copyable (and whether or not you need both Copy= Constructible and CopyAssignable) would be a requirement.  This would = also mean that the algorithm could throw.

Given th= e above surprising behavior (plus the performance difference between using = InputIterators and ForwardIterators), such a proposal is unlikely to go any= where.  IMNSHO this is a solution in search of a problem.
-= -
 Nevin ":-)" Liber  <mailto:ne.= ...@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1464_1703712818.1426914887517-- ------=_Part_1463_2030033701.1426914887517-- .