220 4763 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: Fri, 31 May 2013 09:14:44 -0400 Lines: 116 Approved: news@gmane.org Message-ID: References: <38f0c024-225e-4375-9601-e3bfded295d0@isocpp.org> <5f93f9b8-d0c1-4da6-925f-78eb4d3a139a@isocpp.org> <8770e23c-f631-4ba2-b246-6908acd17784@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158c3020a4db304de03663a X-Trace: ger.gmane.org 1370006089 20343 80.91.229.3 (31 May 2013 13:14:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 May 2013 13:14:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC7JZJ43WYOBBRWEUKGQKGQEWJ3WUQQ@isocpp.org Fri May 31 15:14:49 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f69.google.com ([209.85.161.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UiPAN-0006BL-BZ for gclcip-std-proposals@m.gmane.org; Fri, 31 May 2013 15:14:47 +0200 Original-Received: by mail-fa0-f69.google.com with SMTP id a11sf1558514fad.4 for ; Fri, 31 May 2013 06:14:46 -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=gouQ6xgaiUJnpCMT7V7w2ixXpEot4byfEytiDO0y0Cg=; b=vPJnb9Wo5hY2dBM0CPxa/E+dJVUsUtIXTz22pqB6d3MVm0UyLwSP8bTGzwq3c626Ur TEvDzV7jxqUnzPEKoxq+1tGIEEbPXvxuaVElFYRcEnTa2shPOucG7eTeeYvfLezxnNM6 iQJGp2ZlRGd8l0ouQJaDxtw9o9jBZmt/dJ54rr9UitmKT7vviBOEDSy+s4sx2jZvqf/E JI0acaX1JPoUKFkzD1KN17nvTvy+2ern5X9AF9Di1RAiWLCsCN3VZkFt+tIZIjkpFK4l 1B5lBi0K4CxsWpgnzrW/YNsU5nDjUMXNcxpMu6plcxSjzWJ5r465MuFYrUlYtM8iEvoO WIZw== X-Received: by 10.112.88.168 with SMTP id bh8mr3174247lbb.7.1370006086572; Fri, 31 May 2013 06:14:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.120.35 with SMTP id kz3ls49870lab.13.gmail; Fri, 31 May 2013 06:14:45 -0700 (PDT) X-Received: by 10.152.26.225 with SMTP id o1mr5864456lag.43.1370006085379; Fri, 31 May 2013 06:14:45 -0700 (PDT) Original-Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx.google.com with ESMTPS id ye2si3633833lbb.70.2013.05.31.06.14.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 06:14:45 -0700 (PDT) Received-SPF: pass (google.com: domain of boivina@gmail.com designates 209.85.217.182 as permitted sender) client-ip=209.85.217.182; Original-Received: by mail-lb0-f182.google.com with SMTP id z5so1640200lbh.41 for ; Fri, 31 May 2013 06:14:45 -0700 (PDT) X-Received: by 10.152.22.199 with SMTP id g7mr5084582laf.20.1370006085060; Fri, 31 May 2013 06:14:45 -0700 (PDT) Original-Sender: boivina@gmail.com Original-Received: by 10.114.172.232 with HTTP; Fri, 31 May 2013 06:14:44 -0700 (PDT) In-Reply-To: <8770e23c-f631-4ba2-b246-6908acd17784@isocpp.org> X-Original-Sender: devalexb@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of boivina@gmail.com designates 209.85.217.182 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:4763 Archived-At: --089e0158c3020a4db304de03663a Content-Type: text/plain; charset=ISO-8859-1 Good point. Well, you are guaranteed that the allocation will be on the heap in some situations (where it would not be possible at all to allocate on the stack). That would just be one more of those situations (and only for strict InputIterators which are not ForwardIterators). So I tend to agree as well. On Fri, May 31, 2013 at 8:59 AM, Nicol Bolas wrote: > On Friday, May 31, 2013 5:26:57 AM UTC-7, DeadMG wrote: >> >> I think there's no reason why InputIterator should not be acceptable. It >> would just basically require always allocating on the heap as a result. The >> question is whether that's a justifiable tradeoff. > > > Agreed. Especially since `dynarray` provides absolutely no guarantees for > when it's going to heap allocate vs. stack allocate. > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/zh9HX07F1hk/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, 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. > > > -- --- 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. --089e0158c3020a4db304de03663a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good point. Well, you are guaranteed that the allocation w= ill be on the heap in some situations (where it would not be possible at al= l to allocate on the stack). That would just be one more of those situation= s (and only for strict InputIterators which are not ForwardIterators). So I= tend to agree as well.


On Fri, May 3= 1, 2013 at 8:59 AM, Nicol Bolas <jmckesson@gmail.com> wrot= e:
On Friday, May 31, 2013 5:= 26:57 AM UTC-7, DeadMG wrote:
I think there's no reason why InputIterator should not be acceptable. I= t would just basically require always allocating on the heap as a result. T= he question is whether that's a justifiable tradeoff.

Agreed. Especially since `dynarray` provides absolutely no guarant= ees for when it's going to heap allocate vs. stack allocate.
<= div class=3D"HOEnZb">

--
=A0
---
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/zh= 9HX07F1hk/unsubscribe?hl=3Den.
To unsubscribe from this group and all its topics, send an email to std-pr= oposals+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=3Den.
=A0
=A0

--
 
---
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.
 
 
--089e0158c3020a4db304de03663a-- .