220 25369 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing uncopyable allocators Date: Wed, 30 Mar 2016 10:54:59 +0800 Lines: 155 Approved: news@gmane.org Message-ID: References: <657cb0a7-4854-41c6-963f-5a11cc677157@isocpp.org> <76803d44-a7b2-4bf1-8e5c-268a2c88c48c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DB1EEEB-A5B1-426D-A27F-9B63D730B9D1" X-Trace: ger.gmane.org 1459306523 9157 80.91.229.3 (30 Mar 2016 02:55:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2016 02:55:23 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBC4A5W3QKGQEHF25RAA@isocpp.org Wed Mar 30 04:55:10 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1al6Hl-0005XL-Sd for gclcip-std-proposals@m.gmane.org; Wed, 30 Mar 2016 04:55:10 +0200 Original-Received: by mail-ob0-f200.google.com with SMTP id c10sf53584870obp.0 for ; Tue, 29 Mar 2016 19:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=BT8i9EATablgIgSn17aI0ZHB9asQVbGCztRVui11Ow8=; b=x8wn4iaGt43EZr5/rvP5iIFW/d7VKJVfGcteQks/E3ffF7pHs8JPpBAiM+PDj3Ou42 mwbqcKEOODmR6JW3jFKle63BnbcfGl4DJU+qBliDwdsoGE1uwy6IysfP+EOX9KlWN/hN QAdI8Lv2YIuJwtsJ0fnwAhoNXlhBcEJY5JDEmpRM7odnHq+V3UuJki1fedcGpwSCzclt y8flvkURqar06kPUXTU7uoB5vFIlJs/QaOJ5+F/nspNQTK9W2uSq4Ga7nwRpVxSLzJMV 2h/KJ45alLLL6fM1sHcet0WlRLk0pr3Iv7II2jMPBrdauAT2Ad+wGPSZge5e0AyWZc14 fD9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BT8i9EATablgIgSn17aI0ZHB9asQVbGCztRVui11Ow8=; b=SXXkqTEB0/5BwSLy4Rp1K8vnil628aw+li4X3FySeHhJjHo9hpMgx96lJKu30Vk2yy WDws0CoPXpGW/CDJUAAQWkG33u00mvqVPNQQ8UU2tRJOYz2jA2sWL1bP8/j3tMehUS/+ x+HiDPTLiXJ0ASdQmyxe6OwPr5J4fy9B2t0vBihTDyVDIVUpX1Sr2tm2RnLA39Fq0DYy aMbbtkGSi9GQtzDp6ScX0iuBNV0aIMnquHSLEEN1753Zv/fU4DM5nI0C0pt0CJZZuN8C Hgbq86OtKkaohPmQgPdhdSq7ZFA66S1aR/LEN1dnVsERzBaXvmzRJpibN5g7MhTOrQ0+ 6cfg== X-Gm-Message-State: AD7BkJKBdOmO3dlEljUO2sG50WonEmGeuP5JPjeo+RXgaUxfyvMvl1tb4855wzjT8J9/3A== X-Received: by 10.182.22.48 with SMTP id a16mr3462894obf.29.1459306507895; Tue, 29 Mar 2016 19:55:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.64.179 with SMTP id p19ls112920igs.0.gmail; Tue, 29 Mar 2016 19:55:06 -0700 (PDT) X-Received: by 10.98.71.203 with SMTP id p72mr8958632pfi.165.1459306506839; Tue, 29 Mar 2016 19:55:06 -0700 (PDT) Original-Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com. [2607:f8b0:400e:c03::244]) by mx.google.com with ESMTPS id 5si2871197pfi.35.2016.03.29.19.55.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Mar 2016 19:55:06 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::244 as permitted sender) client-ip=2607:f8b0:400e:c03::244; Original-Received: by mail-pa0-x244.google.com with SMTP id hj7so4267299pac.1 for ; Tue, 29 Mar 2016 19:55:06 -0700 (PDT) X-Received: by 10.66.139.137 with SMTP id qy9mr9010921pab.57.1459306506591; Tue, 29 Mar 2016 19:55:06 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.63]) by smtp.gmail.com with ESMTPSA id 3sm1392523pfn.59.2016.03.29.19.55.03 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 19:55:05 -0700 (PDT) In-Reply-To: <76803d44-a7b2-4bf1-8e5c-268a2c88c48c@isocpp.org> X-Mailer: Apple Mail (2.3096.5) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::244 as permitted sender) smtp.mailfrom=potswa@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:25369 Archived-At: --Apple-Mail=_1DB1EEEB-A5B1-426D-A27F-9B63D730B9D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2016=E2=80=9303=E2=80=9329, at 10:59 PM, quicknir@gmail.com wrote: >=20 > Thanks for the good point about "never equal". >=20 > The fact that the small function optimization takes place outside the all= ocator isn't what makes it impossible (as I later realized) to exploit this= technique for std::function. After all, the small string optimization take= s 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 opt= imization without touching string's source code in any way. The problem is = that std::function type erases its allocator. Since the allocator is not pa= rt of the type, it already lives on the heap from the get-go, so the alloca= tor cannot help you put anything on the stack. I understand why std::functi= on is written this way; it makes sense in the common use case even if it ha= ppens to make this optimization impossible. That=E2=80=99s right for std::function, but you still might take a look at = the function_container class in my library I=E2=80=99ve written one proposal for it already (P0043), and I= =E2=80=99d like for such a thing to be either standard or user-implementabl= e with interoperability with std::function. (The distinction between =E2=80= =9Csmall=E2=80=9D and =E2=80=9Cmedium=E2=80=9D represents unnecessary overh= ead, though.) > > =E2=80=A6 and lest it be overlooked, if these allocators aren=E2=80=99t= copyable, they=E2=80=99re not movable either. >=20 > 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 owning allocator. For anything= that lives entirely on the stack and contains no pointers, copying and mov= ing are equivalent as you point out. So making it uncopyable is the same as= making it unmovable. The problem is I really don't like the idea of unmova= ble objects; they're extremely rare, and hard to work with. The flip side i= s though that the stack owning allocator cannot really copy/move itself wit= hout copying/moving the elements. This may actually be ok as the allocator = is templated on the type it holds, so it can actually move the objects arou= nd if it needs to. I'm not sure which alternative is better/worse. The semantics are what they are what they are, like it or not: the allocato= r isn=E2=80=99t practically able to make another of itself. An allocator should certainly not be aware of the contents of its allocatio= n blocks. For one thing, it can=E2=80=99t assume that they contain construc= ted objects. (This may be sort-of implementable if construct and destroy pe= rform bookkeeping, but not without overhead. And the user is free to reuse = the storage for other things.) Which is easier: 1. An allocator which lives inside a movable and copyable container, but wh= ich is ill-formed if you attempt a move operation on the allocator itself. 2. An allocator which allows copy (and move-as-copy) operations, with surpr= ising and not-allocator-like semantics. =E2=80=9CHard to work with=E2=80=9D is a good thing for objects with tricky= semantics. --=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/B7F34041-242E-434C-B2F1-114B67A7C6F2%40gmail.com= .. --Apple-Mail=_1DB1EEEB-A5B1-426D-A27F-9B63D730B9D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2016=E2=80=9303= =E2=80=9329, at 10:59 PM, = quicknir@gmail.com wrote:

=
Thanks for the good point about= "never equal".

The fac= t that the small function optimization takes place outside the allocator is= n't what makes it impossible (as I later realized) to exploit this techniqu= e for std::function. After all, the small string optimization takes place o= utside 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 source code in any way. The problem is that std:= :function type erases its allocator. Since the allocator is not part of the= type, it already lives on the heap from the get-go, so the allocator canno= t help you put anything on the stack. I understand why std::function is wri= tten this way; it makes sense in the common use case even if it happens to = make this optimization impossible.
<= /blockquote>

That=E2=80=99s right for std::function, but you still might take a= look at the function_container cl= ass in my library  I=E2=80=99ve written one proposal for it already (P0043= ), and I=E2=80=99d like for such a thing to be either standard or user-impl= ementable with interoperability with std:= :function. (The distinction between =E2=80=9Csmall=E2=80=9D and =E2= =80=9Cmedium=E2=80=9D represents unnecessary overhead, though.)

> =E2=80=A6 and lest it be overlooked, if= these allocators aren=E2=80=99t copyable, they=E2=80=99re not movable eith= er.

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 owning allocator. For anything that lives ent= irely on the stack and contains no pointers, copying and moving are equival= ent as you point out. So making it uncopyable is the same as making it unmo= vable. The problem is I really don't like the idea of unmovable objects; th= ey're extremely rare, and hard to work with. The flip side is though that t= he stack owning allocator cannot really copy/move itself without copying/mo= ving the elements. This may actually be ok as the allocator is templated on= the type it holds, so it can actually move the objects around if it needs = to. I'm not sure which alternative is better/worse.

The semantics are what they are= what they are, like it or not: the allocator isn=E2=80=99t practically abl= e to make another of itself.

<= /div>
An allocator should certainly not be aware of the cont= ents of its allocation blocks. For one thing, it can=E2=80=99t assume that = they contain constructed objects. (This may be sort-of implementable if construct and destroy perform bookkeeping, but not without overhead. An= d the user is free to reuse the storage for other things.)

Which is easier:
1. An allocator which lives inside a movable and copyable container, = but which is ill-formed if you attempt a move operation on the allocator it= self.
2. An allocator which allows copy (and move-as-c= opy) operations, with surprising and not-allocator-like semantics.

=E2=80=9CHard to work wit= h=E2=80=9D is a good thing for objects with tricky semantics.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/B7F34041-242E-434C-B2F1-114B67A7C6F2%= 40gmail.com.
--Apple-Mail=_1DB1EEEB-A5B1-426D-A27F-9B63D730B9D1-- .