220 12600 article Path: news.gmane.org!not-for-mail From: Adi Shavit Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Questions about N3949 - Scoped Resource - Generic RAII Wrapper for the Standard Library Date: Sun, 31 Aug 2014 11:21:01 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: References: <038222e0-66c3-4837-b158-e911dffb3c55@isocpp.org> <1DB1B82D-0067-4D01-A054-9113B6D7B3ED@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_104_1249219756.1409509261704" X-Trace: ger.gmane.org 1409509272 3743 80.91.229.3 (31 Aug 2014 18:21:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2014 18:21:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMLX45JSIJBBDWPRWQAKGQELG6ELWI@isocpp.org Sun Aug 31 20:21:04 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XO9kN-0005zh-Js for gclcip-std-proposals@m.gmane.org; Sun, 31 Aug 2014 20:21:03 +0200 Original-Received: by mail-vc0-f198.google.com with SMTP id id10sf14443493vcb.5 for ; Sun, 31 Aug 2014 11:21:02 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=vioptMhbJ8shuJf18OuMyKebkYjxW7R3gK1JjChQ9KA=; b=pT73bGYLAdmbZQg6DdjkkDgrVUrg4sCNdmeQEKJGRlshgFzUH613eTmyuBIK8/beo+ 4+2Nw8vtjprnDrjmSwmW3+jc+gVrNmnuH2NTDaruKewvQsj7mugyZanRNqkB6pl10EA6 EBRmYJGeAsrqMLw1C68Oery1k2koPtsWlmXrHJ+whjvdLYHfa/YlbOeg/sa2P4ORM07a wjigap4EfN/NNNlEfPUPaaW/XEQwX8KQPoM4wYkmg6Zob75GUo1wBdClHs6xnvSgyS4d 2RoULNbA1PhKNMwRetdLq42/f4tOxP4ClAWJmd3t1n9HU2SeN9XiPLRWiw/iZoU6zw1v Kvmw== 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=vioptMhbJ8shuJf18OuMyKebkYjxW7R3gK1JjChQ9KA=; b=WKDg7alLPWzx+hRhHcitpkoNmea4cHatpGU0IHq2/p+iMIxNJskofHuBJO98jTnKd1 bu4y7LHV2R5JzyKbyijunwc6vWTP59XRdP7nM0bLu/8RglZ7s58s7njWnP8DSDV1hL+C ZtnkIT+bkEsfEzggZe7bW89cn+XIZao29cc+ys9O4Ut3JJANfWe8r9kRqroshuz3b/pg +pnj0HPF9iQ0PbgYgw7Jj8arHDSOAewf95oE4wiSDdxS67odaI1YiCpU926N0J4oSWUj Xt+YxVteP2cuCzzSYPCAsIAGR77Yhx4liuXnAF4+aqeuR2yFVCeSgwvGDUgqB1gPugEw OOJA== X-Gm-Message-State: ALoCoQlPaL7pERNTitBqJgd5M1GQmveadMHRsaHjGMsQ+Ikv26JcKXt/b5oui8Ka/ASsYvY+Ytg1 X-Received: by 10.52.74.230 with SMTP id x6mr13210370vdv.6.1409509262758; Sun, 31 Aug 2014 11:21:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.19.203 with SMTP id 69ls1638765qgh.27.gmail; Sun, 31 Aug 2014 11:21:02 -0700 (PDT) X-Received: by 10.140.37.39 with SMTP id q36mr1894qgq.10.1409509262075; Sun, 31 Aug 2014 11:21:02 -0700 (PDT) In-Reply-To: <1DB1B82D-0067-4D01-A054-9113B6D7B3ED@gmail.com> X-Original-Sender: adishavit@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:12600 Archived-At: ------=_Part_104_1249219756.1409509261704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, =20 > The difference between type-erased shared_ptr and fully-static unique_ptr= ,=20 > and its cousin scoped_resource, is an indirect function call. This is=20 > necessary because a shared_ptr can almost never expect to know the=20 > dynamic type of the object it retains, but most unique_ptr use cases=20 > statically know the dynamic type. > Hmmm.. I would think that with shared_ptr with a polymorphic class (where= =20 you do not know the dynamic type), you would actually rely on the virtual= =20 dtor in these cases and would most often stay with the default delete(er).= =20 When trying to wrap C APIs your data would usually not be polymorphic e.g.= =20 opaque values *or* pointers. So it might seems that it is *these* cases where deleter type erasure may= =20 be more useful. For example, OpenGL has many components that are all referenced via simple= =20 int IDs. It is up-to the programmer to keep track of which int ID is which and how= =20 each (resource ) should be released.=20 =20 > The solution is to add your own indirect call into the deleter, such as b= y=20 > using a naked function pointer pointer type as the deleter, or by virtual= =20 > operator (). > How would I do that if my deleter is actually a lambda? It is often the case that a resource release function expects a ref to the= =20 handle, so I would need to wrap it in some lamba. If I have to write a class with a custom dtor for each of my resource kinds= =20 (not necessarily different types), then this whole discussion is moot as it= =20 means this class is not generic enough to let me apply RAII to any (simple)= =20 resource. =20 > For what it=E2=80=99s worth, I=E2=80=99m not convinced that scoped_resour= ce provides any=20 > useful encapsulation. Simply writing a class with a destructor is more=20 > terse and more expository. > When using a 3rd-party C-API (e.g. OpenGL) I often don't want to write a= =20 (yet-another) full blown wrapper library. I just want better resource=20 management. It is always recommended that you handle your resource release at the point= =20 of creation (that is the essence of RAII) - and a resource wrapper should= =20 allow me to do this. If I add/remove resources to/from the code, I do not need to keep track of= =20 initialization and release at different points/methods.=20 =20 > Virtual destructors are among the most widely-known idioms in existence,= =20 > and simply =E2=80=9Cdoing things the old-fashioned way=E2=80=9D would lik= ely have avoided=20 > this deleter confusion entirely. > I am not sure I understand how this applies to our discussion. Thank you, Adi --=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/. ------=_Part_104_1249219756.1409509261704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,
 
The d= ifference between type-erased shared_ptr and = fully-static unique_ptr, and its cousin scoped_resource, is an indirect function call. Thi= s is necessary because a shared_ptr can almos= t never expect to know the dynamic type of the object it retains, but most&= nbsp;unique_ptr use cases statically kno= w the dynamic type.

Hmmm.= .. I would think that with shared_ptr&nbs= p;with a polymorphic class (where you do not know the dynamic type), you wo= uld actually rely on the virtual dtor in these cases and would most of= ten stay with the default delete(er). When trying to wrap C APIs your data = would usually not be polymorphic e.g. opaque values or pointers= ..
So it might seems that it is these cases where dele= ter type erasure may be more useful.
For example, OpenGL has many= components that are all referenced via simple int IDs.
It is up-= to the programmer to keep track of which int ID is which and how each (reso= urce ) should be released. 
 
The solut= ion is to add your own indirect call into the deleter, such as by using a n= aked function pointer pointer type as the deleter, or by virtual operator ().

How would I do that if my deleter is actually a lambda?
It = is often the case that a resource release function expects a ref to the han= dle, so I would need to wrap it in some lamba.

If = I have to write a class with a custom dtor for each of my resource kinds (n= ot necessarily different types), then this whole discussion is moot as it m= eans this class is not generic enough to let me apply RAII to any (simple) = resource.
 
For what it=E2=80=99s worth, I= =E2=80=99m not convinced that scoped_resource= provides any useful encapsulation. Simply writing a class with a destructo= r is more terse and more expository.

<= /div>
 When using a 3rd-party C-API (e.g. OpenGL) I often don't wa= nt to write a (yet-another) full blown wrapper library. I just want better = resource management.
It is always recommended that you handle you= r resource release at the point of creation (that is the essence of RAII) -= and a resource wrapper should allow me to do this.

If I add/remove resources to/from the code, I do not need to keep track o= f initialization and release at different points/methods. 
&= nbsp;
Virtual destructors are among the most widely-kn= own idioms in existence, and simply =E2=80=9Cdoing things the old-fashioned= way=E2=80=9D would likely have avoided this deleter confusion entirely.

I am not sure I understand = how this applies to our discussion.

Thank you,
Adi

--

---
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>.
------=_Part_104_1249219756.1409509261704-- .