220 18340 <064e1cec-7a5b-4550-b694-6570e1702776@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 11:03:47 -0700 (PDT) Lines: 273 Approved: news@gmane.org Message-ID: <064e1cec-7a5b-4550-b694-6570e1702776@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3804_982427710.1433181827443" X-Trace: ger.gmane.org 1433181838 12023 80.91.229.3 (1 Jun 2015 18:03:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 18:03:58 +0000 (UTC) Cc: potswa@mac.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBBF5WKVQKGQEVQYG3XI@isocpp.org Mon Jun 01 20:03:54 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YzU3y-0004d5-1F for gclcip-std-proposals@m.gmane.org; Mon, 01 Jun 2015 20:03:50 +0200 Original-Received: by iecxk8 with SMTP id xk8sf238853426iec.3 for ; Mon, 01 Jun 2015 11:03:49 -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=LFPkaDd0iOCKYsMX5hmY0RIBkzyKp5kPVxde7fJcaDg=; b=X6h/R9rMA4i94A/Rh1IkVaFAL+Y5iL/D0XFlK58zmL7t8H9S8wIrFG1U4tY93yYRpJ DsuUpAhR6NVJThAFUB1TLG4Q82S/RTTwOOgCgfSE2w/T5t1ZD0omcvI4tg/ZDl2q5k4O W+8PN3oAzu0sbIiGCpRLaeJEUYo7Zabe6Nhp0KKyFyVDpdNC45RXVAFyoDNSkNkp0TZ7 BQqHD3oLJqTli0YkJEzunWE/CNtPxp6o9UBrVnjXg0Y9B1+dPBKx0YO1bfRn8YMPF2T4 K3nkxOdCVlkNPrhWS2n2euP1CFStcJ5+EhJTtulUg67OG9cZX3exWlRYSvJJOj5SeGct cFfA== 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=LFPkaDd0iOCKYsMX5hmY0RIBkzyKp5kPVxde7fJcaDg=; b=jPA9DVoIKRPaVATITqU4PxeSpL559jxMhCwn3dMmxhOpiekvQ3Be+hvHXouC6FdYP5 IgSIH1kebljSnI3FADD/uqXTJOQ5FVsi/cDCwPztITgsXTIKF6IOI35wUOG5qjoOFEw1 CpJhtZhjgrVdHS6Q3jdAyyxXqy4nBj5FJdnHELyHqcGCMS1LQqNV9LyHg994R1ny+SP9 nQoqnuPHSgLaZOKxWa5Vk1MdBqkl/xpFXs2GLh9gDkNIsltCbBh48e/y35+spo4Nmw0P fXsxRq/sikWtGLOYM4N6joNT52XGu4ux6BGJ1a7syshjaKyefpgkv9dDCrK5Bnb+u2dR jp3w== X-Gm-Message-State: ALoCoQmFcZNSrDbgbQt+w4+83NfTdMi0U+BsCo8S38SjoxUpLtH+w6vD2FjP+0bwkhnPbQjoh6Z6 X-Received: by 10.182.233.230 with SMTP id tz6mr11444487obc.21.1433181828780; Mon, 01 Jun 2015 11:03:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.91.101 with SMTP id y92ls2794635qgd.43.gmail; Mon, 01 Jun 2015 11:03:48 -0700 (PDT) X-Received: by 10.140.20.40 with SMTP id 37mr46024qgi.26.1433181828118; Mon, 01 Jun 2015 11:03:48 -0700 (PDT) In-Reply-To: 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:18340 Archived-At: ------=_Part_3804_982427710.1433181827443 Content-Type: multipart/alternative; boundary="----=_Part_3805_1808243834.1433181827443" ------=_Part_3805_1808243834.1433181827443 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, June 1, 2015 at 1:33:34 PM UTC-4, David Krauss wrote: > > > On 2015=E2=80=9306=E2=80=9302, at 1:20 AM, Matthew Fioravante > wrote: > > unique_ptr has some limitations: > > 1) It doesn't store the size of the block, so you need to either keep=20 > track of it separately or write a wrapper type, which is essentially what= =20 > I'm talking about. > 2) It only allows you to construct the objects with the default=20 > constructor, which can be very limiting, especially for non-copy/non-move= =20 > types. > > > Both of these can be solved using a custom allocator. > Using a custom allocator to change which constructors are called underneath= =20 seems like a hack to me. I know its in the standard but using it for=20 something like this feels like a hack. I don't just want to call a different constructor, I want to call a=20 different constructor with different arguments for each element and=20 possibly different constructors for the elements themselves. For example if I have this: struct Foo { Foo(int); Foo(const Foo&) =3D delete; Foo(Foo&&) =3D delete; F= oo&=20 operator=3D(const Foo&) =3D delete; Foo& operator=3D(Foo&&) =3D delete; }; std::vector ivec =3D /*something*/; I'd like to be able to construct a fixed_array a, where each element= =20 a[i] is inplace constructed with ivec[i]. If you can do such a thing with a custom allocator, its still very painful= =20 to write. The standard could potentially provide an allocator template=20 which you could feed a lambda for construction which might help. Even with all of that, the allocator becomes part of the array container's= =20 type which is completely unnecessary. We only need the construction logic= =20 during the construction of fixed_array, after that it can be thrown away.= =20 Having different allocators only for this logic confuses things because=20 outside of how they were constructed, 2 such fixed_arrays should be of=20 exactly the same type.=20 Also the copy/move constructors may also call Allocator::construct() and=20 this can be problematic unless you carefully add construct() overloads for= =20 copy/move that don't trigger your lambda. If construct() is implemented using a lambda/functor which has state (i.e.= =20 capture variables), now you have to carry around copies of that state=20 forever with your fixed_array. Outside of the constructor for fixed_array,= =20 this state is never needed again and is likely even invalidated as your=20 fixed_array is passed around to different scopes. Finally, if such a construction mechanism was added for fixed_array, I=20 would see no reason not to also include it for std::array which has no=20 allocator. Maybe this whole concept of inplace construction via lambdas/iterators=20 deserves a thread and proposal of its own. > I've wondered about the omission of std::allocate_unique. Has it ever=20 > come up? > > There would need to be a generic allocator-to-deleter adapter, which=20 > should be generally useful and not too difficult. The general case would= =20 > need to store an element count, because that is expected by=20 > allocator::deallocate. This could be publicly accessible. > --=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_3805_1808243834.1433181827443 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, June 1, 2015 at 1:33:34 PM UTC-4, David= Krauss wrote:

On 2015=E2=80= =9306=E2=80=9302, at 1:20 AM, Matthew Fioravante <fmatth...@gmail.com> wrote:
unique_ptr<T[]&= gt; has some limitations:

1) It doesn't store the size of the block= , so you need to either keep track of it separately or write a wrapper type= , which is essentially what I'm talking about.
2) It only allows you to construc= t the objects with the default constructor, which can be very limiting, esp= ecially for non-copy/non-move types.
Both of these can be solved using a custom allocator.

Using a custom allocator to change which constructors are= called underneath seems like a hack to me. I know its in the standard but = using it for something like this feels like a hack.

I don't just wan= t to call a different constructor, I want to call a different constructor w= ith different arguments for each element and possibly different constructor= s for the elements themselves.

For example if I have this:
<= span style=3D"color: #008;" class=3D"styled-by-prettify">struct Foo { Foo(int); Foo(const Foo&) =3D= delete; Foo(Foo&&) =3D delete= ; Foo& operator=3D(const Foo= &) =3D delete; Foo& opera= tor=3D(Foo&&) =3D delete; };

std::vector= <int>= ; ivec =3D /*something*/;

= I'd like to be able to construct a fixed_array<Foo> a, where each ele= ment a[i] is inplace constructed with ivec[i].

If you can do such a = thing with a custom allocator, its still very painful to write. The standar= d could potentially provide an allocator template which you could feed a la= mbda for construction which might help.

Even with all of that, the a= llocator becomes part of the array container's type which is completely unn= ecessary. We only need the construction logic during the construction of fi= xed_array, after that it can be thrown away.
Having different allocator= s only for this logic confuses things because outside of how they were cons= tructed, 2 such fixed_arrays should be of exactly the same type.

Al= so the copy/move constructors may also call Allocator::construct() and this= can be problematic unless you carefully add construct() overloads for copy= /move that don't trigger your lambda.

If construct() is implemented = using a lambda/functor which has state (i.e. capture variables), now you ha= ve to carry around copies of that state forever with your fixed_array. Outs= ide of the constructor for fixed_array, this state is never needed again an= d is likely even invalidated as your fixed_array is passed around to differ= ent scopes.

Finally, if such a construction mechanism was added for = fixed_array, I would see no reason not to also include it for std::array wh= ich has no allocator.

Maybe this whole concept of inplace constructi= on via lambdas/iterators deserves a thread and proposal of its own.

=

I've wondered about the omission of std::allocate_unique. Has it ever come up?

There would need to be a generic allocator-to-deleter adapt= er, which should be generally useful and not too difficult. The general cas= e would need to store an element count, because that is expected by allocator::deallocate. This could be publicly access= ible.

--

---
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_3805_1808243834.1433181827443-- ------=_Part_3804_982427710.1433181827443-- .