220 18345 <0af21d5d-e95e-41c9-8963-69be0cfbf366@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Use cases for dyn_array Date: Mon, 1 Jun 2015 15:56:17 -0700 (PDT) Lines: 152 Approved: news@gmane.org Message-ID: <0af21d5d-e95e-41c9-8963-69be0cfbf366@isocpp.org> References: <064e1cec-7a5b-4550-b694-6570e1702776@isocpp.org> <7AC283E4-961E-4AC3-8EDF-AB274DC02BCB@mac.com> <955aafda-3636-4881-9e83-ff07240dd0d7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2899_61569601.1433199377879" X-Trace: ger.gmane.org 1433199382 15546 80.91.229.3 (1 Jun 2015 22:56:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 22:56:22 +0000 (UTC) Cc: potswa@mac.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBEWGWOVQKGQEEZE3UUQ@isocpp.org Tue Jun 02 00:56:21 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YzYd2-0007Ra-FO for gclcip-std-proposals@m.gmane.org; Tue, 02 Jun 2015 00:56:20 +0200 Original-Received: by paxu5 with SMTP id u5sf112341622pax.3 for ; Mon, 01 Jun 2015 15:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=5ZuqhoMrhUkdix/cq2SHynhUicW3teWktEMoBpKyNrU=; b=OcQgD3JPi8VSjDDkzafGE/FvnOn38Dksp07HZFkagNDL62TmElL7KOmfwU2N1wpgBO M0r3B8z4kOqz/YTSxW8Di6KNnXztmB9rBuBWwjTHDGDwFn7bseilLSoZdz1pLHlIo3sz 6i8ETEVrMIBTEWcbFpagbyFjcCDYn5CiDjQEOazwak4JerC51RZq0tDORWssSArLppRB dC0hS3QR4ohUtzxaS38r6sWV0vZ2iXqmF3PWFjCD/WrlT3TSvT+misyFTs8uqfM0VQ0b EZyPp8tWpbyIfPq/fkfQZ/tjYL6LS3kh1yoC0xHgoAV9Rn5jddcSaj1+7M1k4kSwe5KD efpA== 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:cc: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=5ZuqhoMrhUkdix/cq2SHynhUicW3teWktEMoBpKyNrU=; b=awqbnDz8bSxqSuqVV6WmBpmkoNgoXchh0KhNPx+kS+xMjiUOyKUekWZE86+HVCdHdD LUqyMX3z85yAJu/LVfRhEbrTpjxkMeA6VkKqRX0Ryql8uKUENl2ZkBXH1/20NnKRBm0D KVgZ2xV10BUd1y6fEh6IwES7UzHwdl9I0cFyvDlMUBRD+s7WROg4BZrmT4KWil/KfTsN hbgGwWwobmdSCR9o51NTi3SgCAjCzZ7BC1c3dpfvaMqT21C4lEWuSWsvvS1tyZnENTLI X3o/X6Ry28YlVxE66XnPzyf5pjwsQgfoPSTae996qOmUAc25GUF/6xM+MGfnQWGZAgKQ wIVA== X-Gm-Message-State: ALoCoQkFxVyg5f5hbuzDYkp6/OPVnN7LhFfTuPfaOGUAoAp5g20Hi03+lWwIqsoT1KttQEFn7QNM X-Received: by 10.66.121.79 with SMTP id li15mr30803457pab.12.1433199379338; Mon, 01 Jun 2015 15:56:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.102.204 with SMTP id w70ls2945277qge.56.gmail; Mon, 01 Jun 2015 15:56:18 -0700 (PDT) X-Received: by 10.140.19.170 with SMTP id 39mr42083qgh.9.1433199378451; Mon, 01 Jun 2015 15:56:18 -0700 (PDT) In-Reply-To: <955aafda-3636-4881-9e83-ff07240dd0d7@isocpp.org> X-Original-Sender: fmatthew5876@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:18345 Archived-At: ------=_Part_2899_61569601.1433199377879 Content-Type: multipart/alternative; boundary="----=_Part_2900_1860649800.1433199377879" ------=_Part_2900_1860649800.1433199377879 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 1, 2015 at 6:40:08 PM UTC-4, Nicol Bolas wrote: > > > > On Monday, June 1, 2015 at 3:20:47 PM UTC-4, David Krauss wrote: >> >> >> On 2015=E2=80=9306=E2=80=9302, at 2:12 AM, Matthew Fioravante =20 >> wrote: >> >> Also unique_ptr does not have any builtin copy semantics. >> >> >> I don=E2=80=99t think dyn_array is ever likely to support copying, eithe= r. (It=E2=80=99s=20 >> way past my bedtime so maybe I shouldn=E2=80=99t bet against that having= been=20 >> proposed at some point.) >> >> It sounds like what you really want is a non-resizable version of=20 >> std::vector, with a std::piecewise_construct constructor. >> > > It seems to me that, with N4416=20 > =20 > (PDF), you'd basically have that: a way to know exactly how much memory= =20 > std::vector allocated, rather than hoping that vector::reserve didn't=20 > over-allocate. > Possibility of over-allocating is only one of the many problems. I know its easier to just tack on some functions to vector than create a=20 whole new class, but is this really the right way to do it? A fixed size=20 array (movable T or not) is a completely different problem then an array=20 that can grow, and different problems should be modelled by different types= =20 so the compiler can make it impossible for us to make classes of mistakes. If I'm given a vector from somewhere, I don't know if it is intended to be= =20 used in an emplace_back_capped() context or an emplace_back() context. Also= =20 this reserve_initially() business would be better done in the constructor. Also we're still forced to store a capacity, wasting valuable cache line=20 space. If I have a fixed size array and I can construct all of the elements= =20 at container construction time using a variadic polymorphic lambda with=20 iterators, I don't need to keep track of the capacity in the container. An= =20 array type that doesn't even have a push_back(), resize(), etc.. methods=20 can not be used incorrectly. It also still doesn't solve the general problem of constructing a container= =20 with non-movable types. Right now it is impossible to specify which=20 constructors and which args to those constructors when building a=20 std::array. --=20 ---=20 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 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-proposa= ls/. ------=_Part_2900_1860649800.1433199377879 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, June 1, 2015 at 6:40:08 PM UTC-4, Nicol= Bolas wrote:
=

On Monday, June 1, 2015 at 3:20:47 PM UTC-4, David Krauss wrote:
On 2015=E2=80=9306=E2=80=9302, at 2:1= 2 AM, Matthew Fioravante <fmatth...@gmail.com>= ; wrote:

Also unique_ptr<T[]> does not= have any builtin copy semantics.

I don=E2=80=99t think dyn_array is eve= r likely to support copying, either. (It=E2=80=99s way past my bedtime so m= aybe I shouldn=E2=80=99t bet against that having been proposed at some poin= t.)

It sounds like what you really want is a non-r= esizable version of std::vector, with a std::piecewise_construct constructor.
<= /div>

It seems to me that, with N4416 (PDF), you'd basically have that: a way to know exactly h= ow much memory std::vector allocated, rather than hoping that vector::reser= ve didn't over-allocate.

Possibility of ov= er-allocating is only one of the many problems.

I know its easier to= just tack on some functions to vector than create a whole new class, but i= s this really the right way to do it? A fixed size array (movable T or not)= is a completely different problem then an array that can grow, and differe= nt problems should be modelled by different types so the compiler can make = it impossible for us to make classes of mistakes.

If I'm given a vec= tor from somewhere, I don't know if it is intended to be used in an emplace= _back_capped() context or an emplace_back() context. Also this reserve_init= ially() business would be better done in the constructor.

Also we're= still forced to store a capacity, wasting valuable cache line space. If I = have a fixed size array and I can construct all of the elements at containe= r construction time using a variadic polymorphic lambda with iterators, I d= on't need to keep track of the capacity in the container. An array type tha= t doesn't even have a push_back(), resize(), etc.. methods can not be used = incorrectly.

It also still doesn't solve the general problem of cons= tructing a container with non-movable types. Right now it is impossible to = specify which constructors and which args to those constructors when buildi= ng a std::array<NonMovableType,N>.

--

---
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_2900_1860649800.1433199377879-- ------=_Part_2899_61569601.1433199377879-- .