220 23758 <1c315b77-38b7-46b8-8105-2703b4dccb6d@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 22:36:04 -0800 (PST) Lines: 156 Approved: news@gmane.org Message-ID: <1c315b77-38b7-46b8-8105-2703b4dccb6d@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_3458_1883215125.1453012564714" X-Trace: ger.gmane.org 1453012576 30545 80.91.229.3 (17 Jan 2016 06:36:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2016 06:36:16 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCH65356YUARBVXM5S2AKGQE43QOJSY@isocpp.org Sun Jan 17 07:36:09 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aKgwa-0001JO-R2 for gclcip-std-proposals@m.gmane.org; Sun, 17 Jan 2016 07:36:09 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id a202sf455034672oib.1 for ; Sat, 16 Jan 2016 22:36:08 -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=T9xsPDRcrxyW0UGIZ0DMXGMvzggrnNVXLKVGix81XtQ=; b=mORXIb6mIBwYh2HyRt2dnRCZZQsijWLEm8gxhSx7bj4lABo2/Tjf6nxduLr3xXpmzC 3WyRfH2L3AAHOPql6XypyZrWRhKwKMWWlH+Mf4MYJyklNlMxmR7PILl5LLSD4nqrMJxa 0NVFK8PwqTSebvGNOkeGt3AYUA3S4+No2KRdwu1F9d0uM6ElfYdiihDtC48djF5FMepl QVsYFos2GuHACKzzuYWv0sR2u0K1SSN5To1jrMWOVzvSq6ksqMFssaiBQoP3k1xfRjwP p2tGpUUHpbe5RhbHFJTm6p2ZyxMrUvnmoXeQDQ1uJycLE2vqisJACN1mMxzduZkiy+99 nYUQ== 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=T9xsPDRcrxyW0UGIZ0DMXGMvzggrnNVXLKVGix81XtQ=; b=zCVO9KN3YLGkoXuOpM7hyDl4SZGIDksiUmMVJ2MOUrdirsICq8jBgxVdWrTX1g1ahG c/xoiNcE6CLuZVO/4Xxf376zRK0ETqpR3V26qBUdNCvwhRzgUfqJtloe+qZSMRY9FqIh dKtaG1Y83YvLSUXjOKLLI0pY9+XnBQzA5086Tzjvny5Mny21H/hVwr1/EZLTxBw+26/z HoorX0+vFq9ik58jdGaOhyRJ+VuYlI+eYBVEi7B4AzGi6Jdp1L3e2CQ0nJvPr0vgYd11 jjLkwJAbhu8yK1GNSihJIIDnrpEzcrLym+1wJ9VSuYLf/KgkXER1ByVvuSB9nHYpcIx/ 5ZCg== 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=T9xsPDRcrxyW0UGIZ0DMXGMvzggrnNVXLKVGix81XtQ=; b=Debf7R5H6P2oyEll0D7DQMy5At4Y31jyOblMopG1ssjqpco8hcpHTXJWkqW6Blw9iZ JK5LHijJd/ja+PC8Xfg+kFf64VE6nkmJNLeDsUGykyc9DdIitlnADToCLiI+K/8lgeSK PIOGBBqOw+BL2E8bbvePoRDtukrHWNVLQxW0uPIwDDCzr/BPNYvhReu1vmsuoM9zw7hs yjGsvKKOp9q3KlGrhiDymrtZLRRp3McHjr1oRuI7apTrjvOdtLiEdagh8gBtCY8v/74U +qerBrwy1cB+XCZlHHO/BgVZZba8VG0voy43tJDJbg9y/LCTPVx3lVurg8VpoEkqRoCF zCBA== X-Gm-Message-State: ALoCoQkt2tHauuMOcuQOvBGX+2vQiyT9+XHQhg/movTfHP6QSLRY7ElbmgocK+hXyohBvrjAP5DlJ5ZJ48Sg99ks2jqYBDvK/w== X-Received: by 10.182.236.34 with SMTP id ur2mr16735362obc.10.1453012567757; Sat, 16 Jan 2016 22:36:07 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.128.76 with SMTP id b73ls886337iod.101.gmail; Sat, 16 Jan 2016 22:36:06 -0800 (PST) X-Received: by 10.50.115.69 with SMTP id jm5mr111622igb.10.1453012566350; Sat, 16 Jan 2016 22:36: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:23758 Archived-At: ------=_Part_3458_1883215125.1453012564714 Content-Type: multipart/alternative; boundary="----=_Part_3459_287592463.1453012564714" ------=_Part_3459_287592463.1453012564714 Content-Type: text/plain; charset=UTF-8 While this proposal may make it easier to implement such containers, and may even cause certain containers of certain standard library types to happen to work with such an allocator, this is not sufficient. 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. Any allocator written in that environment would be non-portable, which isn't acceptable for many. It's still necessary to change the definition of a conforming allocator. This proposal may make it so that the standard library doesn't have to make any changes to have compliant containers, but that is all, and even that I'm not certain about. Even without this proposal it is certainly possible to make things work, though it may be trickier. The proposal in any case seems to be largely about situations where at least a move can be guaranteed instead of a copy, it is just that total elision cannot be guaranteed. In this situation, moving is fine, it's that actual unnecessary copies are taking place. Let me know if you feel I've misunderstood. On Saturday, January 16, 2016 at 11:12:21 PM UTC-5, Zhihao Yuan wrote: > > On Sat, Jan 16, 2016 at 5:38 PM, > > wrote: > > > > SimpleAllocator(const SimpleAllocator&) { std::cerr << "copy\n"; }; > > SimpleAllocator(SimpleAllocator&&) = default; > > SimpleAllocator& operator=(const SimpleAllocator&) = delete; > > SimpleAllocator& operator=(SimpleAllocator&&) = default; > > > > SimpleAllocator select_on_container_copy_construction() const { > > std::cerr << "blah\n"; > > return SimpleAllocator{}; > > } > > There won't be any issue after > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html > > being accepted. > > -- > 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_3459_287592463.1453012564714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While this proposal may make it easier to implement s= uch containers, and may even cause certain containers of certain standard l= ibrary types to happen to work with such an allocator, this is not sufficie= nt. Even if copy elision is mandatory under certain circumstances, this doe= sn'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. Any allocator written in that environment would be = non-portable, which isn't acceptable for many. It's still necessary= to change the definition of a conforming allocator.

This proposal may make it so that the standard library doesn't have = to make any changes to have compliant containers, but that is all, and even= that I'm not certain about. Even without this proposal it is certainly= possible to make things work, though it may be trickier. The proposal in a= ny case seems to be largely about situations where at least a move can be g= uaranteed instead of a copy, it is just that total elision cannot be guaran= teed. In this situation, moving is fine, it's that actual unnecessary c= opies are taking place.

Let me know if you feel I&= #39;ve misunderstood.


On Saturday, January 16, 2016= at 11:12:21 PM UTC-5, Zhihao Yuan wrote:
On Sat, Jan 16, 2016 at 5:38 PM, =C2=A0<quic...@gmail.com> = wrote:
>
> =C2=A0 SimpleAllocator(const SimpleAllocator&) { std::cerr <= ;< "copy\n"; };
> =C2=A0 SimpleAllocator(SimpleAllocator&&) =3D default= ;
> =C2=A0 SimpleAllocator& operator=3D(const SimpleAllocator&= ) =3D delete;
> =C2=A0 SimpleAllocator& operator=3D(SimpleAllocator&&)= =3D default;
>
> =C2=A0 SimpleAllocator select_on_container_copy_construction(= ) const {
> =C2=A0 =C2=A0 std::cerr << "blah\n";
> =C2=A0 =C2=A0 return SimpleAllocator{};
> =C2=A0 }

There won't be any issue after

=C2=A0 http://ww= w.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html

being accepted.

--=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_3459_287592463.1453012564714-- ------=_Part_3458_1883215125.1453012564714-- .