220 4755 article Path: news.gmane.org!not-for-mail From: Alex B Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Traversable arg for dynarray constructor Date: Thu, 30 May 2013 22:09:51 -0400 Lines: 99 Approved: news@gmane.org Message-ID: References: <38f0c024-225e-4375-9601-e3bfded295d0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c36dae38329904ddfa1cc3 X-Trace: ger.gmane.org 1369966193 14944 80.91.229.3 (31 May 2013 02:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 May 2013 02:09:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC7JZJ43WYOBB4MMUCGQKGQEX5NW4DI@isocpp.org Fri May 31 04:09:54 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-bk0-f72.google.com ([209.85.214.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UiEmw-0004cq-DM for gclcip-std-proposals@m.gmane.org; Fri, 31 May 2013 04:09:54 +0200 Original-Received: by mail-bk0-f72.google.com with SMTP id jf20sf844924bkc.11 for ; Thu, 30 May 2013 19:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=G9X06yHbK2Z6N3oPuQjpN7pirRyWwVo8Y5byyEVcFFE=; b=Bv2snQfRhgzn9Vkhh0ZZ4amPEJcBgbUaYfpnXw5JWx2muksA8TIbarEaykXyVDHiO3 71ooLurmNojG24yp0RkY0NK3pvbB/aTW2lqGO+1fNf4Otc+y76YIqiuxEvUgPvysSkQ/ nuE8BgCGuJvDiUVRjnZHclNN49/unKZvEsnYLjdyNCZW7zEJTIqAAi9zuCEgsaNdOpdI PPK6nH1RS6GATYIUylgLT/FQS5KDDYvudEhLBSXYOZ0y0YeBImByGA4f37GoFZFqLfUQ OEbhZv+QoPp5S5cTafkwBkvtNDRxTMAftt8rbjUqyontpzbyBIzXGTEWLriFsKh8IvL2 k5Aw== X-Received: by 10.152.1.5 with SMTP id 5mr2590006lai.3.1369966193752; Thu, 30 May 2013 19:09:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.170.233 with SMTP id ap9ls36819lac.19.gmail; Thu, 30 May 2013 19:09:52 -0700 (PDT) X-Received: by 10.112.22.6 with SMTP id z6mr2487266lbe.43.1369966192286; Thu, 30 May 2013 19:09:52 -0700 (PDT) Original-Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [2a00:1450:4010:c03::22d]) by mx.google.com with ESMTPS id e4si5248039lag.35.2013.05.30.19.09.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 19:09:52 -0700 (PDT) Received-SPF: pass (google.com: domain of boivina@gmail.com designates 2a00:1450:4010:c03::22d as permitted sender) client-ip=2a00:1450:4010:c03::22d; Original-Received: by mail-la0-f45.google.com with SMTP id fr10so905193lab.4 for ; Thu, 30 May 2013 19:09:52 -0700 (PDT) X-Received: by 10.112.188.161 with SMTP id gb1mr4972754lbc.107.1369966191848; Thu, 30 May 2013 19:09:51 -0700 (PDT) Original-Sender: boivina@gmail.com Original-Received: by 10.114.172.232 with HTTP; Thu, 30 May 2013 19:09:51 -0700 (PDT) In-Reply-To: X-Original-Sender: devalexb@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of boivina@gmail.com designates 2a00:1450:4010:c03::22d as permitted sender) smtp.mail=boivina@gmail.com; dkim=pass header.i=@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:4755 Archived-At: --001a11c36dae38329904ddfa1cc3 Content-Type: text/plain; charset=ISO-8859-1 I guess if we strictly look at what is possible to implement, indeed the requirement should be ForwardIterator, which is less restrictive than BidirectionalIterator. I suppose that the intent of the writers of the proposal was mainly to avoid two passes because a lot of users won't expect it (unless I'm wrong, it would be the first container doing it). Indeed, if we strictly look at the complexity level, doing two passes doesn't change anything; 2 times linear remains linear. However, concretely it could result in twice the time taken to execute this constructor (in the worst case scenario). For some people, it will mater (even if the overall complexity level is the same) because it will be far from obvious to the average user. But I admit that I am not among those caring much about this 'performance penalty' of doing 2 passes. My goal was to find a compromise that wouldn't harm anybody because I thought there was a consensus about avoiding it. I would personally find it better to have the most unrestricted requirements so that we could have the following uniform behavior (expected from most users): a standard container (including dynarray) can always be constructed from *any* other standard container (either with a pair of iterators or with a range as suggested by the other proposal). And to achieve it, I would not mind doing two passes for iterators other than random access iterators. I personally think the benefits of using a dynarray in such a situation where you need to copy the content of another container/range far outweighs the penalty of doing two passes (assuming the dynarray will most probably use memory from the stack instead of the heap). All that being said, maybe the authors of the dynarray paper could share what was their own reasoning about not providing the said constructor? -- --- 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/?hl=en. --001a11c36dae38329904ddfa1cc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I guess if we strictly look at what is possible to impleme= nt, indeed the requirement should be ForwardIterator, which is less restric= tive than BidirectionalIterator. I suppose that the intent of the writers o= f the proposal was mainly to avoid two passes because a lot of users won= 9;t expect it (unless I'm wrong, it would be the first container doing = it).

Indeed, if we strictly look at the complexity level, do= ing two passes doesn't change anything; 2 times linear remains linear. = However, concretely it could result in twice the time taken to execute this= constructor (in the worst case scenario). For some people, it will mater (= even if the overall complexity level is the same) because it will be far fr= om obvious to the average user.

But I admit that I am not among those caring much about= this 'performance penalty' of doing 2 passes. My goal was to find = a compromise that wouldn't harm anybody because I thought there was a c= onsensus about avoiding it. I would personally find it better to have the m= ost unrestricted requirements so that we could have the following uniform b= ehavior (expected from most users): a standard container (including dynarra= y) can always be constructed from any=A0other standard container (ei= ther with a pair of iterators or with a range as suggested by the other pro= posal). And to achieve it, I would not mind doing two passes for iterators = other than random access iterators. I personally think the benefits of usin= g a dynarray in such a situation where you need to copy the content of anot= her container/range far outweighs the penalty of doing two passes (assuming= the dynarray will most probably use memory from the stack instead of the h= eap).

All that being said, maybe the authors of the dyn= array paper could share what was their own reasoning about not providing th= e said constructor?

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
--001a11c36dae38329904ddfa1cc3-- .