220 4756 article Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Traversable arg for dynarray constructor Date: Fri, 31 May 2013 08:05:37 +0200 Lines: 48 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: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1369980341 4441 80.91.229.3 (31 May 2013 06:05:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 May 2013 06:05:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCT7RVFA4QORBMX3UCGQKGQEMN75AHY@isocpp.org Fri May 31 08:05:41 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f197.google.com ([209.85.215.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UiIT6-0004sA-CQ for gclcip-std-proposals@m.gmane.org; Fri, 31 May 2013 08:05:40 +0200 Original-Received: by mail-ea0-f197.google.com with SMTP id z7sf1062336eaf.4 for ; Thu, 30 May 2013 23:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version: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=DPZgsc1EFGyatEiGHDycml306+Qi3A9s9BlK79Nswuk=; b=ReaAN3CdVu/Xq7nurvjncg17INGYofprVFxX+ungueQENlSoMWZTLUY2I6OGcqZuP4 fQ42+r/GhKbqI5lp4rh3p6HaTU5E+dFNM8l29cDuR29wV9CDnKar6sEBWFiLlpTv1GU9 71GTa+N9f10Jku9rPdwuCqCuzln6BtlTkCDPzj642n2wjAyM8pbQzrE3ntmAJCOfD64r YH4QNxGPv39ZjnD7Ks+tFvDG4JSHa5CPxSAetqySjTLLcB82lvKGYWqtRQOGw7fBkzyh jmUDpngX61s1D/G9CrIFF9u5T4erOSyNKNYB/RISxwfK5ogkuK3eW5GBBCbFOUp4/xGe cnQg== X-Received: by 10.180.21.226 with SMTP id y2mr847590wie.5.1369980339596; Thu, 30 May 2013 23:05:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.75.202 with SMTP id e10ls129957wiw.8.canary; Thu, 30 May 2013 23:05:37 -0700 (PDT) X-Received: by 10.180.79.40 with SMTP id g8mr1801455wix.3.1369980337676; Thu, 30 May 2013 23:05:37 -0700 (PDT) Original-Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [2a00:1450:400c:c00::229]) by mx.google.com with ESMTPS id gj3si801645wic.21.2013.05.30.23.05.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 23:05:37 -0700 (PDT) Received-SPF: pass (google.com: domain of daniel.kruegler@gmail.com designates 2a00:1450:400c:c00::229 as permitted sender) client-ip=2a00:1450:400c:c00::229; Original-Received: by mail-wg0-f41.google.com with SMTP id k13so384281wgh.2 for ; Thu, 30 May 2013 23:05:37 -0700 (PDT) X-Received: by 10.194.235.130 with SMTP id um2mr7828075wjc.30.1369980337521; Thu, 30 May 2013 23:05:37 -0700 (PDT) Original-Received: by 10.216.211.194 with HTTP; Thu, 30 May 2013 23:05:37 -0700 (PDT) In-Reply-To: X-Original-Sender: daniel.kruegler@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of daniel.kruegler@gmail.com designates 2a00:1450:400c:c00::229 as permitted sender) smtp.mail=daniel.kruegler@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:4756 Archived-At: 2013/5/31 Alex B : > 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). I agree that ForwardIterator should be feasible. > 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. Neither would I. > 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). Agreed. - Daniel -- --- 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. .