220 21075 article Path: news.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: optional_ptr - A smart pointer which optionally owns the resource Date: Wed, 30 Sep 2015 16:31:55 -0700 Lines: 142 Approved: news@gmane.org Message-ID: References: <7502c195-e5b9-4f04-8997-666933cef239@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d52ca0034410520ff56e8 X-Trace: ger.gmane.org 1443655919 4826 80.91.229.3 (30 Sep 2015 23:31:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 23:31:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIOZYNRWACRUBDT5D7VU@isocpp.org Thu Oct 01 01:31:59 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f200.google.com ([209.85.212.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZhQqr-000707-Eh for gclcip-std-proposals@m.gmane.org; Thu, 01 Oct 2015 01:31:57 +0200 Original-Received: by wicgb1 with SMTP id gb1sf1671605wic.3 for ; Wed, 30 Sep 2015 16:31:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=teUWWnjHxX2Qcd+M5q3x8OYZKYPvFAZ6S0xsCniIDKw=; b=NwtFgQgqwQi8PPJDWTkFtjiz8JNOLSZgUgWGMzNscRLBqj1Ia0w/8M83HXuMsya75d CqddiHasZIasXIb5IApjzJoZhbI8cjUB7Im7eGaiTOUpGLHdxe0jaaC8PT6MbyQc8ikY ZxlT2qQ0jUNAU1HErXAZI/xfeGrC4Ry3FnkXAfJ2dcasePMI7c5y368ketcRuYEg7bi9 WORoYhkvZgcDrpGQT4V4s3XdLKV/IjvGuhPchnZBiTOIJts3joGbfuXEtDeWW4ku8x/p pcc/O2I09NKKU+Z0WaOdO6t4E1cnfO0rHqM3H1ZlWf3No+wTo8HPLcn+RUcaEqn0PrLb Fs9g== X-Gm-Message-State: ALoCoQmIOXn9ultZG2YUZ3MH93f0heNArx2HKYFHTdyABTsF99QpdGM5PnvtjcvsUWaJiXJisQpF X-Received: by 10.112.169.34 with SMTP id ab2mr924079lbc.23.1443655916753; Wed, 30 Sep 2015 16:31:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.109.137 with SMTP id hs9ls22702wib.29.canary; Wed, 30 Sep 2015 16:31:55 -0700 (PDT) X-Received: by 10.194.118.5 with SMTP id ki5mr6928916wjb.94.1443655915585; Wed, 30 Sep 2015 16:31:55 -0700 (PDT) Original-Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com. [2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id eu7si66271wic.44.2015.09.30.16.31.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 16:31:55 -0700 (PDT) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) client-ip=2a00:1450:400c:c05::230; Original-Received: by wicgb1 with SMTP id gb1so4974357wic.1 for ; Wed, 30 Sep 2015 16:31:55 -0700 (PDT) X-Received: by 10.194.22.165 with SMTP id e5mr6797283wjf.50.1443655915153; Wed, 30 Sep 2015 16:31:55 -0700 (PDT) Original-Received: by 10.27.132.68 with HTTP; Wed, 30 Sep 2015 16:31:55 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dkim=pass header.i=@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:21075 Archived-At: --047d7b5d52ca0034410520ff56e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 30, 2015 at 1:32 PM, wrote: > On Thursday, September 24, 2015 at 9:35:28 AM UTC-7, Matthew Fioravante > wrote: >> >> The heavy handed solution to use shared_ptr everywhere. Now everyone is >> an owner. Using shared_ptr adds runtime overhead to manage the reference >> count. The biggest problem with shared_ptr is that once you use it in on= e >> place, you have to use it everywhere. Everything now must be dynamically >> allocated individually. You can't allocate 20 objects in an array and vi= ew >> one of them. You can't create objects on the stack or as a data member. >> Forcing individual dynamic allocation is a performance killer. We use C+= + >> because we need to be fast and a big part of being fast beings avoiding >> allocations or failing that, batching them into fewer allocations of lar= ge >> contiguous cache friendly chunks. >> > > You can, with the shared_ptr aliasing constructor (which I just discovere= d > yesterday): > std::shared_ptr> owner =3D ...; > std::shared_ptr viewer(owner, &(*owner)[5]); > // viewer shares ownership of the vector but points to a specific > element > > Or, less safe but potentially faster: > std::vector owner =3D ...; > std::shared_ptr viewer(std::shared_ptr(), &owner[5]); > // viewer owns no object (so no atomic inc/dec will happen) but point= s > to owner[5] > Nit on the latter suggestion: shared_ptr(shared_ptr&&, T*) does not exist, so the above makes an unnecessary copy. This is more like a defect in the Standard than a problem with the above idiom, though. =E2=80=93Arthur P.S. on a pet peeve topic: The Standard wording is super subtle w.r.t. the differences between - an empty object (i.e. one with no control block) - an expired object (i.e. a weak_ptr with a control block whose strong ref count is zero) - an object whose stored pointer is null In particular, it appears from my current reading of N4296 that after std::shared_ptr sptr1 =3D nullptr; std::shared_ptr sptr2 =3D (int *)nullptr; sptr1 must be an empty object whose stored pointer is null, but sptr2 must be a *non-empty* object whose stored pointer is null. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7b5d52ca0034410520ff56e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 30, 2015 at 1:32 PM, <j4cbo@dropbox.com&= gt; wrote:
=
On Thursday, September 24, 2015 at 9:35:2= 8 AM UTC-7, Matthew Fioravante wrote:
The heavy handed solution to use shared_ptr everywhere. Now everyone is an= owner. Using shared_ptr adds runtime overhead to manage the reference coun= t. The biggest problem with shared_ptr is that once you use it in one place= , you have to use it everywhere. Everything now must be dynamically allocat= ed individually. You can't allocate 20 objects in an array and view one= of them. You can't create objects on the stack or as a data member. Fo= rcing individual dynamic allocation is a performance killer. We use C++ bec= ause we need to be fast and a big part of being fast beings avoiding alloca= tions or failing that, batching them into fewer allocations of large contig= uous cache friendly chunks.

You= can, with the shared_ptr aliasing constructor (which I just discovered yes= terday):
=C2=A0 =C2=A0 std::shared_ptr<std::vector<Thing>= ;> owner =3D ...;
=C2=A0 =C2=A0 std::shared_ptr<Thing&g= t; viewer(owner,=C2=A0&(*owner)[5]);
=C2=A0 =C2=A0 /= / viewer shares ownership of the vector but points to a specific element

Or, less safe but potentially faster:
=C2=A0 =C2=A0 std::vector<Thing> owner =3D ...;
=C2= =A0 =C2=A0 std::shared_ptr<Thing> viewer(std::shared_ptr<Thing>= (), &owner[5]);
=C2=A0 =C2=A0 // viewer owns no object (so no= atomic inc/dec will happen) but points to owner[5]

Nit on the latter suggestion:
shared_ptr(sha= red_ptr<Y>&&, T*) does not exist, so the above makes an unnec= essary copy.
This is more like a defect in the Standard than a pr= oblem with the above idiom, though.

=E2=80=93Arthu= r

P.S. on a pet peeve topic: The Standard wording = is super subtle w.r.t. the differences between
- an empty object = (i.e. one with no control block)
- an expired object (i.e. a weak= _ptr with a control block whose strong ref count is zero)
- an ob= ject whose stored pointer is null

In particular, i= t appears from my current reading of N4296 that after

<= div>=C2=A0 =C2=A0 std::shared_ptr<int> sptr1 =3D nullptr;
= =C2=A0 =C2=A0 std::shared_ptr<int> sptr2 =3D (int *)nullptr;

sptr1 must be an empty object whose stored pointer is null= , but
sptr2 must be a non-empty object whose stored pointe= r is null.

--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b5d52ca0034410520ff56e8-- .