220 23760 <73ba89a0-c952-42cc-9df8-3f27a6d98df3@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: Sat, 16 Jan 2016 23:50:04 -0800 (PST) Lines: 140 Approved: news@gmane.org Message-ID: <73ba89a0-c952-42cc-9df8-3f27a6d98df3@isocpp.org> References: <657cb0a7-4854-41c6-963f-5a11cc677157@isocpp.org> <1c315b77-38b7-46b8-8105-2703b4dccb6d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1380_967909574.1453017004963" X-Trace: ger.gmane.org 1453017012 3057 80.91.229.3 (17 Jan 2016 07:50:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2016 07:50:12 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCH65356YUARBLUP5W2AKGQEZ6NYCYI@isocpp.org Sun Jan 17 08:50:08 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aKi6C-0006Ba-2J for gclcip-std-proposals@m.gmane.org; Sun, 17 Jan 2016 08:50:08 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id w75sf360216793oie.0 for ; Sat, 16 Jan 2016 23:50:07 -0800 (PST) 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 :content-type: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=ePgx0W8nNLu+M/x0BB1Bd12BMezHl/m8J0QdLfgTeG8=; b=qwmeezB6uqWxPuxIHeBeevbod0FysA1e8JRGqc4ogO71vF3mJb8Fje5+9GgyY3Q7I+ ihY3hZyDXCNBWGnlCDwejkxLSfTzdwm1ktV3TmNv77Y4hcVkQTLwoAZ3vT2LhQOstHoD 7aQ06EqFoVBkZvdMHkConP2QQ2p1N2ZkFPaWDUCB4oQ8rGlhtOvusjTq6F0TMxp/thbs fuO2liY9Pc5zJnHU6hUXjLBF72t+rJCl5sjIkdAa7T3N/3pFEL0wv+ovchzRpviBR2tC K0OQSQLvwCaH73/jcDQg3vvUYpQUQGEjLIBuannxdlzBjHKy7YYmIFyFm7sjnvycOlN9 n+Sw== 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 :content-type: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=ePgx0W8nNLu+M/x0BB1Bd12BMezHl/m8J0QdLfgTeG8=; b=UHKFF8BpKwU+RAQfVAYLimxd2UhhFgqFfnapqFAdsoz0atenRRpUegCluuYun/MCg6 gv5I/RNuZ9fBickU0D0sYPGbBcdJVpyGWnZMfDh/ACQmwU37f4kfQ8Cm4aBjPKb2Ujp7 jX1NgwCz4kOvGtoEGltNlALmS6MmjnaZIqz5b4ngXMJoAJHvdFlV1QV2uGPJ341Mt8d4 VJX9+ug/TF6HrP897UEzFZVJOsvnKEVICyrPLehjGClQil7i6KqUoXp9CYu5WSRoZeJJ 67WPCKet96SteryGJ8GnfHnh8aSvJrYVk8y3QmCck1H6ZFyfW0XEkoVeWAtNWKTTU2Pw Kiwg== 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:content-type: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=ePgx0W8nNLu+M/x0BB1Bd12BMezHl/m8J0QdLfgTeG8=; b=X/x99+kKMmTjPBzzJnl2Asq+iCD1I1jzLZDSK9A/Lp6ERjdpo4XqISS4f9GytRPBrB NoaCVqKxRbXaBzEHO4U2uv29tIMgUHuqu71M5gdUywof9SGLZuX8rK8aKBdY//qrcAwI wmBiIAzPiz5/WRD5Wz7TlA9l48FeXqP2K4KvEL28TyHwQGH53KvJ1+cTUpU4gKGRo2qd nous3TjFyGYWkyikbK7o27z+Wct42rEnMIjPl73krc8JGVeV6PLmLBUPZEf1RXqKI4Cs +j/e+HhJnSUTOdm26ydmG1eb8D7fsc7GcLlF63R3BbKScP79Cgc9U1usTz9w/pmAzTkg 2eog== X-Gm-Message-State: ALoCoQl9b4JD3ccGxEitNth00Xl0EogTwY6TVwV1qsTnmF/VZEzD60L6zp3s3PJ9MliKV/uqS6gxaNc63tBD6wl8Tlai6EJJeg== X-Received: by 10.107.34.144 with SMTP id i138mr17861946ioi.18.1453017007005; Sat, 16 Jan 2016 23:50:07 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.111.234 with SMTP id il10ls555442igb.18.canary; Sat, 16 Jan 2016 23:50:06 -0800 (PST) X-Received: by 10.50.41.5 with SMTP id b5mr113581igl.8.1453017006039; Sat, 16 Jan 2016 23:50:06 -0800 (PST) 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:23760 Archived-At: ------=_Part_1380_967909574.1453017004963 Content-Type: multipart/alternative; boundary="----=_Part_1381_2079785636.1453017004963" ------=_Part_1381_2079785636.1453017004963 Content-Type: text/plain; charset=UTF-8 THat would be one solution, and the preferred one. I don't see a big problem with taking it by value. Since it is stored by value, slicing is not an issue. And a copy is being made anyway, passing by value when a copy is needed is accepted practice. Another solution would be to leave the pass by const ref but eliminate the default, and then provide additional overloads that simply construct the allocator internally. This is less desirable as it will limit uncopyable allocators to default construction. Not sure what polymorphic means in this context (polymorphic allocator?), but I did give three use cases. I've literally seen examples of people rewriting std::function from scratch so that they could change the size of the small function optimization because heap allocation is a major issue for them. I've also seen people ask about having a small vector optimization. Right now, people are forever saddled with the standard library's decisions when it comes to small object stack optimization, this seems like something allocators should be able to do. I think my other two examples are good as well; memory pools are great in many cases, but they certainly are a hassle, there are both liffetime and threading issues with them. A chunk allocator for std::map seems like an almost free (minor memory cost) performance boost. On Sunday, January 17, 2016 at 2:38:39 AM UTC-5, Zhihao Yuan wrote: > > On Sun, Jan 17, 2016 at 12:36 AM, > > wrote: > > Even if copy elision is mandatory under certain circumstances, this > doesn't > > change the fact that a conforming implementation is free to copy around > > allocators as much as it wants, because a conforming allocator has to be > > copy constructible. > > I see where the "problem" is. But this will require changing all > functions taking a default constructed allocator as const& in the > signatures. > > And you need to convince people about why it's useful. > To me, only polymorphic memory resource is useful; other > people may have different opinions. > > -- > Zhihao Yuan, ID lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://bit.ly/blog4bsd > -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1381_2079785636.1453017004963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
THat would be one solution, and the preferred one. I don&#= 39;t see a big problem with taking it by value. Since it is stored by value= , slicing is not an issue. And a copy is being made anyway, passing by valu= e when a copy is needed is accepted practice. Another solution would be to = leave the pass by const ref but eliminate the default, and then provide add= itional overloads that simply construct the allocator internally. This is l= ess desirable as it will limit uncopyable allocators to default constructio= n.

Not sure what polymorphic means in this context (poly= morphic allocator?), but I did give three use cases. I've literally see= n examples of people rewriting std::function from scratch so that they coul= d change the size of the small function optimization because heap allocatio= n is a major issue for them. I've also seen people ask about having a s= mall vector optimization. Right now, people are forever saddled with the st= andard library's decisions when it comes to small object stack optimiza= tion, this seems like something allocators should be able to do. I think my= other two examples are good as well; memory pools are great in many cases,= but they certainly are a hassle, there are both liffetime and threading is= sues with them. A chunk allocator for std::map seems like an almost free (m= inor memory cost) performance boost.

On Sunday, January 17, 2016 at = 2:38:39 AM UTC-5, Zhihao Yuan wrote:
On Sun, Jan 17, 2016 at 12:36 AM, =C2=A0<quic...@gmail.com> wrot= e:
> Even if copy elision is mandatory under certain circumstances, thi= s doesn't
> change the fact that a conforming implementation is free to copy a= round
> allocators as much as it wants, because a conforming allocator has= to be
> copy constructible.

I see where the "problem" is. =C2=A0But this will require cha= nging all
functions taking a default constructed allocator as const& in the
signatures.

And you need to convince people about why it's useful.
To me, only polymorphic memory resource is useful; other
people may have different opinions.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4b= sd

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_1381_2079785636.1453017004963-- ------=_Part_1380_967909574.1453017004963-- .