220 25368 <76803d44-a7b2-4bf1-8e5c-268a2c88c48c@isocpp.org> article Path: news.gmane.org!not-for-mail From: quicknir@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing uncopyable allocators Date: Tue, 29 Mar 2016 07:59:48 -0700 (PDT) Lines: 290 Approved: news@gmane.org Message-ID: <76803d44-a7b2-4bf1-8e5c-268a2c88c48c@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_5550_2113064325.1459263588912" X-Trace: ger.gmane.org 1459264419 25104 80.91.229.3 (29 Mar 2016 15:13:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2016 15:13:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCH65356YUARBZVQ5K3QKGQECJFCN4Y@isocpp.org Tue Mar 29 17:13:33 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1akv7a-0000qD-Bu for gclcip-std-proposals@m.gmane.org; Tue, 29 Mar 2016 16:59:54 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id u128sf29792726qkh.0 for ; Tue, 29 Mar 2016 07:59:53 -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=2+gbt85OS+8oIOfGw44bnGvXH9oAzoR+giUiSvCUfSY=; b=WoX11ekdJqw+04DlzeLLk6LoU9R16suj4XX2R98qo6nSuSUJ2hAf/t/4JzdK79HdEl fjSUdpYfWrRw0EwfdwHuWB8W0am5MVlnPmYrvo1Tiyp+wDHh+x0+uTj1eld/1itj8+lw 55HenWOtNOuTlWkBzBZvrS95Dqz707JLTtD20coECfXkLiOrqVrxvGSjNN8u/s2g4x+l IJVF1z4L043FE3NOOkqxDTvJUZ74knxLJhGw8oiUwBu+uB6tUptVYLJ4QuY1y8HHhJ6I cidAWzPwPzDTDncqhU8lOnN6UOdo7tjln1VNczx5fg+BE7SgRGt1/tI3vlU8JvlCRmSP 9Z1Q== 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=2+gbt85OS+8oIOfGw44bnGvXH9oAzoR+giUiSvCUfSY=; b=u521/GT83xyNgWqa/8fuV1q8zO3qXJ6ln61OJyfa4ECn/gxVD4P5Qa/s0TLQk7tsjN EZ6cbZsqWaQXm6aH3UKankZ2FzF4UoNCKfC/JmwXgENf9mmBUyhoA+7MWMoxQ35k9sn3 XcsQvEah4slZpKv/BX0hopCQ2+8Zmse0rs8veqZN2ZWWU/8+2hd0EH6hur4ASRQhlYK6 TYuFEeVGNnJ8R5/EoqsBfjYMml3sZbHj6RkvyxZ7xDwTxprxfZNPBllBH2xYvTfJ2TDt ALPmAG+j76mRsxUjUMI+TBDAV/mOA0orHC81H1lTTTlTrXZ5Uel4ai9Wx8lVgZJ2tRi0 GDNw== 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=2+gbt85OS+8oIOfGw44bnGvXH9oAzoR+giUiSvCUfSY=; b=SyBZk3ltbBI48FIdSmWoOHndunXr/bN5VLWe9e6/MAbnmCdoH4J5AMnNM/coLxuzz7 Dbxv7O2ibu9rexmVwZwWbqXKQs+4n38Ws6FftGOHPwxin4PFXzbdtWsF/cU4JqHc0iXW vnguEqyhC6SWUvPFV8XxaVZV1DAjQRz4OywVuM6Syl+WqG3uHJyXVa0HTEYZWgHR4IMy V3fdoQeVLr6+R1lZJSLG5vWnO4hzMcHFsFuVgTrrYDv+ZPbhE9FXBBhV//m6klmUy+5K Fw8PsbNGuqbtY3LTYZ9OWNHWlfK4dIo00aGOpWDYBosEFSj9C+i7qJBLOPUs4/iVWz6d 6E0Q== X-Gm-Message-State: AD7BkJK4BqoU6ezDwMoSSxY/DCjYWKrLjuznRuVwtI3WFG9qd8ZK8NokNbD+OyHi7JfEUQ== X-Received: by 10.31.169.130 with SMTP id s124mr1484159vke.1.1459263591559; Tue, 29 Mar 2016 07:59:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.79.136 with SMTP id j8ls208847igx.3.gmail; Tue, 29 Mar 2016 07:59:49 -0700 (PDT) X-Received: by 10.50.153.109 with SMTP id vf13mr61486igb.10.1459263589599; Tue, 29 Mar 2016 07:59:49 -0700 (PDT) In-Reply-To: X-Original-Sender: quickNir@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:25368 Archived-At: ------=_Part_5550_2113064325.1459263588912 Content-Type: multipart/alternative; boundary="----=_Part_5551_1600389903.1459263588913" ------=_Part_5551_1600389903.1459263588913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the good point about "never equal". The fact that the small function optimization takes place outside the=20 allocator isn't what makes it impossible (as I later realized) to exploit= =20 this technique for std::function. After all, the small string optimization= =20 takes place outside the allocator for string, yet it would still be=20 possible to write an allocator that owns stack resources and get a "medium"= =20 string optimization without touching string's source code in any way. The= =20 problem is that std::function type erases its allocator. Since the=20 allocator is not part of the type, it already lives on the heap from the=20 get-go, so the allocator cannot help you put anything on the stack. I=20 understand why std::function is written this way; it makes sense in the=20 common use case even if it happens to make this optimization impossible. > =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. Yes, that is a good point. It took me a while to parse Yun's post. I may=20 need to think a bit more about a stack-space owning allocator. For anything= =20 that lives entirely on the stack and contains no pointers, copying and=20 moving are equivalent as you point out. So making it uncopyable is the same= =20 as making it unmovable. The problem is I really don't like the idea of=20 unmovable objects; they're extremely rare, and hard to work with. The flip= =20 side is though that the stack owning allocator cannot really copy/move=20 itself without copying/moving the elements. This may actually be ok as the= =20 allocator is templated on the type it holds, so it can actually move the=20 objects around if it needs to. I'm not sure which alternative is=20 better/worse. On Saturday, March 26, 2016 at 12:59:20 PM UTC-4, 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. > > > 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/76803d44-a7b2-4bf1-8e5c-268a2c88c48c%40isocpp.or= g. ------=_Part_5551_1600389903.1459263588913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the good point about "never equal".
The fact that the small function optimization takes place= outside the allocator isn't what makes it impossible (as I later reali= zed) to exploit this technique for std::function. After all, the small stri= ng optimization takes place outside the allocator for string, yet it would = still be possible to write an allocator that owns stack resources and get a= "medium" string optimization without touching string's sourc= e code in any way. The problem is that std::function type erases its alloca= tor. Since the allocator is not part of the type, it already lives on the h= eap from the get-go, so the allocator cannot help you put anything on the s= tack. I understand why std::function is written this way; it makes sense in= the common use case even if it happens to make this optimization impossibl= e.

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

Yes, that is a good point. It took me a while to = parse Yun's post. I may need to think a bit more about a stack-space ow= ning allocator. For anything that lives entirely on the stack and contains = no pointers, copying and moving are equivalent as you point out. So making = it uncopyable is the same as making it unmovable. The problem is I really d= on't like the idea of unmovable objects; they're extremely rare, an= d hard to work with. The flip side is though that the stack owning allocato= r cannot really copy/move itself without copying/moving the elements. This = may actually be ok as the allocator is templated on the type it holds, so i= t can actually move the objects around if it needs to. I'm not sure whi= ch alternative is better/worse.

On Saturday, March 26, 2016 at 12:59= :20 PM UTC-4, David Krauss wrote:

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

But wha= t if your allocators want to own their own resources? Such allocators can n= ever really allocate or deallocate each other's pointers, so they can n= ever compare equal. This sounds like a big deal, but if your allocator is u= ncopyable, then it's not an issue; there's no real situation where = you would ever necessarily expect them to compare equal.

I= t would be nice to see this avenue pursued. It would allow =E2=80=9Csmall= =E2=80=9D or =E2=80=9Clocal=E2=80=9D vectors to be specializations of std::vector. Locally-optimized versions of all the= standard containers would appear for minimal effort.

=

On 2016=E2=80=9301= =E2=80=9317, at 12:12 PM, Zhihao Yuan <z...@miator.net> wrote:
=
There won't be any issue after

=C2=A0http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html

being accepted.

The interface for initializing an= d retrieving the internal allocator would need to be revised, 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 obtain a reference = to a 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 mea= ns in this context (polymorphic allocator?),
=
Polymorphic allocators exist on the opposite end of the over= all problem domain of allocators. Every allocator object gets reduced to a = polymorphic pointer, and every allocation and deallocation is dispatched as= a virtual function. This helps interoperability at the expense of performa= nce. It=E2=80=99s part of the Fundamentals TS; it may or may not be adopted= by C++17.

I've literally seen examples of people rew= riting std::function from scratch so that they could change the size of the= small function optimization because heap allocation is a major issue for t= hem.

This seems to be fairly common= .. Unfortunately, the small function optimization takes place outside the al= locator. You could perhaps hack a local allocator into my=C2=A0function_container=C2=A0te= mplate. But you=E2=80=99d want to forbid converting that back to an ordinar= y function, or else do something clever like = heap-allocate the local allocator. The library doesn=E2=80=99t provide for = that. Also, the ordinary small-function optimization would be made redundan= t=E2=80=A6 it=E2=80=99s possible that this is an entirely different problem= ..


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

We should extend it to move construction thro= ugh select_on_container_move_construction, as we need the ability of d= efault constructing the allocator too. This would be required to move const= ruct an container in an arena from stack. =C2=A0
=E2=80=A6 and lest it be overlooked, if these 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/76803d44-a7b2-4bf1-8e5c-268a2c88c48c= %40isocpp.org.
------=_Part_5551_1600389903.1459263588913-- ------=_Part_5550_2113064325.1459263588912-- .