220 25382 <137dc707-14b3-417f-9a06-362c466ef47d@isocpp.org> article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing uncopyable allocators Date: Wed, 30 Mar 2016 18:07:57 -0700 (PDT) Lines: 262 Approved: news@gmane.org Message-ID: <137dc707-14b3-417f-9a06-362c466ef47d@isocpp.org> References: <657cb0a7-4854-41c6-963f-5a11cc677157@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8693_980243304.1459386478134" X-Trace: ger.gmane.org 1459386487 2782 80.91.229.3 (31 Mar 2016 01:08:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 01:08:07 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCDODCNR2QPRB37Q6G3QKGQEOUM6F2A@isocpp.org Thu Mar 31 03:08:02 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1alR5d-0002CL-C8 for gclcip-std-proposals@m.gmane.org; Thu, 31 Mar 2016 03:08:01 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id q128sf137725748iof.1 for ; Wed, 30 Mar 2016 18:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9+3QdYta9fYtogtuT7XGLxV0J6TQasv7Yukn5+TpL3Y=; b=tQrOwBJRK1PxH4fJsuFVY6GUY6RfRvzi3swVhLoNqqa+vTNauqOirZn9AL3NN0p+Zm Wc5Yh25lOuKo/lvyC5p04E6YkW8MMKeZCjBDD2FeLu5f7N83XkfKQMmlu1I/YIRynqIl Ygc5jbGwBw4xtd86sqqkLEm0lWZvkV7L8pNllhONhsG6Oau+WbXkTl7iT4mFfSNDrI+M XQ1AZLQk0/fArBriyeFdk2w/VrWwHWZifgW4Nd8lebpRecc3zsW8L1j5ZfxuqmyBhhX5 XUugjDKIyxyidW93SeOTIbJ9jgdIoxeIAPey529nd1o95JaMLjPXDykS4o36yFQvarN1 /XeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9+3QdYta9fYtogtuT7XGLxV0J6TQasv7Yukn5+TpL3Y=; b=z14tkA0rJScOc6E+hXG8/UeRxq7/r8+xzc0JRFkl5Tyu9unI6k9SS4XFWak4584/z+ k8GaBBEkEtuDT+a9UFqEPH8SCjyYjZPuhwV0IdUULY8z6xmylkOMr5+X0lVVXm8fH/rI Fj33vutokGAw7aTd1uE/Y2rxaapR2BxR3Jv63p2agEfhbLfuRFwMvhAadzhAF8sw0AJ/ ApSr7b+ONqWHE0+dGk3LqM9n7PN6YLLmnnnkAuF47FH9200u7f1F+KgxBE8M2ub2Dk6s PS9Xj+hbGAK0Yh62SoUxa8VEptAY755BXeKZV6hnQ08Ebaxz+N0T81TnCp2n5Mt5A76h t9WQ== 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:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=9+3QdYta9fYtogtuT7XGLxV0J6TQasv7Yukn5+TpL3Y=; b=Ix6wZ30ca24Z8fHcqMNwxxHWUiOt9nvmco8e+BdNia4aqp24A/e2ANbxyAHHySUubU J81yzg2mo4QvJyhtyGmIlCC3cL+btuuiTEEnGx3alqJb2oTh+dVLPG9HiGpZO+rWA5c4 +m738JqB06YBjUA5jlpl6dwcW/D0I7oVoJWc8Pr4lDZtGgWDPTvVfEfhe2mML7YPg1pV I1UV13jEBVRDb++ABh+4ykSzFoi/WLJPZ/Th0pePexQJ+ETu5Xgsa/K1zQubG9hxVW5w nlUgXJQ57PUI1ZT9vE0gXofyOh/fdPGfNocQdCmmQHrtoTjtceHlCDyoJjkwpmcFhW96 g94g== X-Gm-Message-State: AD7BkJJUNllWLfQY74+61UjKsvv53YdpooPXKiHQwmUZKFzaDHMmEIyK5x+5r2lMyypvjg== X-Received: by 10.157.50.203 with SMTP id u69mr6988924otb.13.1459386480103; Wed, 30 Mar 2016 18:08:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.114.74 with SMTP id je10ls489430igb.42.gmail; Wed, 30 Mar 2016 18:07:58 -0700 (PDT) X-Received: by 10.50.155.72 with SMTP id vu8mr283054igb.5.1459386478823; Wed, 30 Mar 2016 18:07:58 -0700 (PDT) In-Reply-To: X-Original-Sender: Sean.Middleditch@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25382 Archived-At: ------=_Part_8693_980243304.1459386478134 Content-Type: multipart/alternative; boundary="----=_Part_8694_621060238.1459386478134" ------=_Part_8694_621060238.1459386478134 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, March 26, 2016 at 9:59:20 AM UTC-7, David Krauss wrote: > > > On 2016=E2=80=9301=E2=80=9317, at 7:38 AM, quic...@gmail.com wrote: > > But what if your allocators want to own their own resources? Such=20 > allocators can never really allocate or deallocate each other's pointers,= =20 > so they can never compare equal. This sounds like a big deal, but if your= =20 > allocator is uncopyable, then it's not an issue; there's no real situatio= n=20 > where you would ever necessarily expect them to compare equal. > > > It would be nice to see this avenue pursued. It would allow =E2=80=9Csmal= l=E2=80=9D or=20 > =E2=80=9Clocal=E2=80=9D vectors to be specializations of std::vector. Loc= ally-optimized=20 > versions of all the standard containers would appear for minimal effort. > Not by itself. There's still that small problem where the allocator has no= =20 idea what growth pattern the vector uses while the vector has no idea what= =20 the best initial size classes for the allocator would be. There's an extra= =20 missing bit of "protocol" needed between the two in order to fully=20 genericize "small" or "fixed" containers like vector. Otherwise you end up= =20 with allocators that have room for up to 7 elements while the container=20 tries to allocate room for an initial capacity of 16 elements. The naive approach would work for just the small/fixed container use case.= =20 A good approach would likely work for other cases, e.g. a page allocator=20 backing a vector requiring that the vector grow only in=20 multiple-of-page-size increments. =20 > > > On 2016=E2=80=9301=E2=80=9317, at 12:12 PM, Zhihao Yuan >=20 > wrote: > > There won't be any issue after > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html > > being accepted. > > > The interface for initializing and retrieving the internal allocator woul= d=20 > need to be revised, at least for the new local allocators. It would be ni= ce=20 > to even remove it, but querying the remaining capacity is too useful. > > (Regarding =E2=80=9Cnever equal,=E2=80=9D pedantically, if you can obtain= a reference to a=20 > local allocator, then it should compare equal to itself.) > > > On 2016=E2=80=9301=E2=80=9317, at 3:50 PM, quic...@gmail.com wrote: > > > Not sure what polymorphic means in this context (polymorphic allocator?), > > > Polymorphic allocators exist on the opposite end of the overall problem= =20 > domain of allocators. Every allocator object gets reduced to a polymorphi= c=20 > pointer, and every allocation and deallocation is dispatched as a virtual= =20 > function. This helps interoperability at the expense of performance. It= =E2=80=99s=20 > part of the Fundamentals TS; it may or may not be adopted by C++17. > > I've literally seen examples of people rewriting std::function from=20 > scratch so that they could change the size of the small function=20 > optimization because heap allocation is a major issue for them. > > > This seems to be fairly common. Unfortunately, the small function=20 > optimization takes place outside the allocator. You could perhaps hack a= =20 > local allocator into my function_container=20 > template. But you=E2=80=99d want= to=20 > forbid converting that back to an ordinary function, or else do something= =20 > clever like heap-allocate the local allocator. The library doesn=E2=80=99= t provide=20 > for that. Also, the ordinary small-function optimization would be made=20 > redundant=E2=80=A6 it=E2=80=99s possible that this is an entirely differe= nt problem. > > > On 2016=E2=80=9303=E2=80=9326, at 11:44 PM, Yun Chen >=20 > wrote: > > We should extend it to move construction through=20 > select_on_container_move_construction, as we need the ability of default= =20 > constructing the allocator too. This would be required to move construct = an=20 > container in an arena from stack. =20 > > > =E2=80=A6 and lest it be overlooked, if these allocators aren=E2=80=99t c= opyable, they=E2=80=99re=20 > not movable either. > > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/137dc707-14b3-417f-9a06-362c466ef47d%40isocpp.or= g. ------=_Part_8694_621060238.1459386478134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, March 26, 2016 at 9:59:20 AM UTC-7, David Kra= uss wrote:

On 2016=E2=80= =9301=E2=80=9317, at 7:38 AM, quic...@gmail.com wrote:

But what if your allocators wa= nt to own their own resources? Such allocators can never really allocate or= deallocate each other's pointers, so they can never compare equal. Thi= s sounds like a big deal, but if your allocator is uncopyable, then it'= s not an issue; there's no real situation where you would ever necessar= ily expect them to compare equal.

<= span style=3D"float:none;display:inline!important">It would be nice to see = this avenue pursued. It would allow =E2=80=9Csmall=E2=80=9D or =E2=80=9Cloc= al=E2=80=9D vectors to be specializations of std::ve= ctor. Locally-optimized versions of all the standard containers woul= d appear for minimal effort.

=
Not by itself. There's still that small problem where the allocato= r has no idea what growth pattern the vector uses while the vector has no i= dea what the best initial size classes for the allocator would be. There= 9;s an extra missing bit of "protocol" needed between the two in = order to fully genericize "small" or "fixed" containers= like vector. Otherwise you end up with allocators that have room for up to= 7 elements while the container tries to allocate room for an initial capac= ity of 16 elements.

The naive approach would work = for just the small/fixed container use case. A good approach would likely w= ork for other cases, e.g. a page allocator backing a vector requiring that = the vector grow only in multiple-of-page-size increments.

The interface f= or initializing and retrieving the internal allocator would need to be revi= sed, at least for the new local allocators. It would be nice to even remove= it, but querying the remaining capacity is too useful.

(Regarding =E2=80=9Cnever equal,=E2=80=9D pedantically, if you can ob= tain a reference to a local allocator, then it should compare equal to itse= lf.)


On 2= 016=E2=80=9301=E2=80=9317, at 3:50 PM, quic...@gmail.com wrote:

Not sure wh= at polymorphic means in this context (polymorphic allocator?),
=

Polymorphic allocators exist on the opposi= te end of the overall problem domain of allocators. Every allocator object = gets reduced to a polymorphic pointer, and every allocation and deallocatio= n is dispatched as a virtual function. This helps interoperability at the e= xpense of performance. It=E2=80=99s part of the Fundamentals TS; it may or = may not be adopted by C++17.

I've literally seen exam= ples of people rewriting std::function from scratch so that they could chan= ge the size of the small function optimization because heap allocation is a= major issue for them.

This seems t= o be fairly common. Unfortunately, the small function optimization takes pl= ace outside the allocator. You could perhaps hack a local allocator into my= =C2=A0function_container=C2=A0template. But you=E2=80=99d want to forbid converting that = back to an ordinary function, or else do some= thing clever like heap-allocate the local allocator. The library doesn=E2= =80=99t provide for that. Also, the ordinary small-function optimization wo= uld be made redundant=E2=80=A6 it=E2=80=99s possible that this is an entire= ly different problem.


On 2016=E2=80=9303=E2=80=9326, at 11:44 PM, Yun Chen <= yun.g= ....@gmail.com> wrote:

We should extend it to move= construction through select_on_container_move_construction, as we nee= d the ability of default constructing the allocator too. This would be requ= ired to move construct an container in an arena from stack. =C2=A0

=E2=80=A6 and lest it be overlooked, if thes= e allocators aren=E2=80=99t copyable, they=E2=80=99re not movable either.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/137dc707-14b3-417f-9a06-362c466ef47d= %40isocpp.org.
------=_Part_8694_621060238.1459386478134-- ------=_Part_8693_980243304.1459386478134-- .