220 12602 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Questions about N3949 - Scoped Resource - Generic RAII Wrapper for the Standard Library Date: Mon, 1 Sep 2014 08:19:27 +0800 Lines: 226 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 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_16AB018A-4F8E-4D70-B97D-3EDF0F926E84" X-Trace: ger.gmane.org 1409530791 9642 80.91.229.3 (1 Sep 2014 00:19:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Sep 2014 00:19:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBHPXR2QAKGQEHVVCVTY@isocpp.org Mon Sep 01 02:19:44 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XOFLT-0006g0-OH for gclcip-std-proposals@m.gmane.org; Mon, 01 Sep 2014 02:19:44 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id lf10sf57490054pab.1 for ; Sun, 31 Aug 2014 17:19:42 -0700 (PDT) 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=2CgDxTgcU9DOr1Qcv1I7HjkojTE5GUO33g+sqBZJUeE=; b=aNLe8Csooj5qrkJFwzKP2x1/nFRfJLycnQheseYmDdeQpngdUy4jtvjHIuaBX15RxT dIsQjCm9oNXPi8Ho6TDRgQ8IBtePlh5fBbKXdwXjtCM3TM3e35O4XAfsiXCoO4RFQzGl EOGlaNiySVxlcejhnVGhzzSoykOs6UKB7ZWqjkc4eBbh11iiUvksN7IcXzaXAnRJSq3K YPqW4Wghzd5b4CPvDzecBBYClTPWpDueNkrXdLfoCLK7473UHviyoFtClCtRGeXhrhFs ey2O9vZGVOa0OeMy6kIFke55UYcc/d5SQIUXT5JyEC8mcVlmjfQMO8iRuH7SblIQ308F aSXA== X-Gm-Message-State: ALoCoQl1XrtUjasZ/Sxj86io+o0n/9HxBCDlJl2o1rMGuS0OfXtBUDSvveVsyGsfQpRBQVAfpaeW X-Received: by 10.66.160.164 with SMTP id xl4mr1260872pab.48.1409530782546; Sun, 31 Aug 2014 17:19:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.44.43 with SMTP id b11ls1559953igm.19.gmail; Sun, 31 Aug 2014 17:19:41 -0700 (PDT) X-Received: by 10.68.94.226 with SMTP id df2mr7447857pbb.122.1409530781472; Sun, 31 Aug 2014 17:19:41 -0700 (PDT) Original-Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [2607:f8b0:400e:c02::22b]) by mx.google.com with ESMTPS id jb8si10691594pbd.78.2014.08.31.17.19.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 17:19:41 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c02::22b as permitted sender) client-ip=2607:f8b0:400e:c02::22b; Original-Received: by mail-pd0-f171.google.com with SMTP id y13so4780034pdi.2 for ; Sun, 31 Aug 2014 17:19:41 -0700 (PDT) X-Received: by 10.68.162.3 with SMTP id xw3mr62563pbb.142.1409530781176; Sun, 31 Aug 2014 17:19:41 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.152]) by mx.google.com with ESMTPSA id pi6sm22305797pac.9.2014.08.31.17.19.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 17:19:40 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c02::22b as permitted sender) smtp.mail=potswa@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12602 Archived-At: --Apple-Mail=_16AB018A-4F8E-4D70-B97D-3EDF0F926E84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-09-01, at 2:21 AM, Adi Shavit wrote: > For example, OpenGL has many components that are all referenced via simpl= e int IDs. > It is up-to the programmer to keep track of which int ID is which and how= each (resource ) should be released.=20 An excellent job for a class. Define one class per type of resource. > The solution is to add your own indirect call into the deleter, such as b= y using a naked function pointer type as the deleter, or by virtual operato= r (). >=20 > How would I do that if my deleter is actually a lambda? Captureless lambdas implicitly convert to a naked function pointer, and del= eters are stateless/captureless, so use that alternative. > It is often the case that a resource release function expects a ref to th= e handle, so I would need to wrap it in some lamba. You don't need a lambda; they have no special abilities that cannot be atta= ined otherwise. They can capture local variables, but your use case, along = with most use cases of scoped_resource, precludes captures being very usefu= l. > If I have to write a class with a custom dtor for each of my resource kin= ds (not necessarily different types), then this whole discussion is moot as= it means this class is not generic enough to let me apply RAII to any (sim= ple) resource. Use a polymorphic class. > For what it's worth, I'm not convinced that scoped_resource provides any = useful encapsulation. Simply writing a class with a destructor is more ters= e and more expository. >=20 > When using a 3rd-party C-API (e.g. OpenGL) I often don't want to write a= (yet-another) full blown wrapper library. I just want better resource mana= gement. > It is always recommended that you handle your resource release at the poi= nt of creation (that is the essence of RAII) - and a resource wrapper shoul= d allow me to do this. You can define a polymorphic class locally. // header struct opengl_resource { GLuint id; opengl_resource( GLuint in_id ) : id( in_id ) {} virtual ~ opengl_resource() =3D 0; }; inline opengl_resource::~ opengl_resource() =3D default; typedef std::unique_ptr< opengl_resource > opengl_handle; // implementation void foo() { struct shader : opengl_resource { using opengl_resource::opengl_resource; virtual ~ shader() { glDeleteShader( id ); } }; // Pass this handle out to any structure/function: opengl_handle sh =3D std::make_unique< shader >( glCreateShader( GL_VER= TEX_SHADER ) ); } Over time, you can migrate the local classes into a wrapper library. There = is no commitment to either keeping everything local precluding reusability = nor to a "full-blown" library (although I don't see the risk in developing = such a thin library as you go). There is a little boilerplate, but it's totally obvious how everything work= s. No room for error. Destructors are (usually) implicitly noexcept, so using a non-noexcept func= tion to define destructor functionality loses a little safety. The traditio= nal way on the other hand is essentially perfect. > Virtual destructors are among the most widely-known idioms in existence, = and simply "doing things the old-fashioned way" would likely have avoided t= his deleter confusion entirely. >=20 > I am not sure I understand how this applies to our discussion. Every workable solution deserves consideration. The apparent problem is mer= ely that you believe classes should be declared in interface headers, but y= ou want to have implementation classes. C++ has always supported implementa= tion classes. Besides local classes, there are also unnamed namespaces. The= re is no need to go back to the bad old days of function pointers. --=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/. --Apple-Mail=_16AB018A-4F8E-4D70-B97D-3EDF0F926E84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 2014&= ndash;09–01, at 2:21 AM, Adi Shavit <adishavit@gmail.com> wrote:

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 an= d how each (resource ) should be released. 

An excellent job for a class. Define one class per type o= f resource.

The solution is to add your own indirect call into the deleter,= such as by using a naked function pointer type as the deleter, or by virtual operator ().
How would I do that if my deleter is actually a lambda?
<= /div>

Captureless lambdas implicitly conver= t to a naked function pointer, and deleters are stateless/captureless, so u= se that alternative.

It is often the case that a resource release function expects a ref to t= he handle, so I would need to wrap it in some lamba.

You don’t need a lambda; they have no special a= bilities that cannot be attained otherwise. They can capture local variable= s, but your use case, along with most use cases of s= coped_resource, precludes captures being very useful.

If I have to write a class with = a custom dtor for each of my resource kinds (not necessarily different type= s), then this whole discussion is moot as it means this class is not generi= c enough to let me apply RAII to any (simple) resource.

Use a polymorphic class.

For what it’s worth= , I’m not convinced that scoped_resource provides any useful encapsulation. Simply writing a class with a destruct= or is more terse and more expository.

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

You can define a polymorphic class locally.

<= /div>
// header
struct opengl_resource {
&n= bsp;   GLuint id;

<= /div>
    opengl_resource( GLuint in_i= d ) : id( in_id ) {}
    = virtual ~ opengl_resource() =3D 0;
= };
inline opengl_resource::~ opengl= _resource() =3D default;

typedef std::unique_ptr< opengl_resource > opengl_handle;

// implementation
void foo= () {
    struct shader : = opengl_resource {
    &nb= sp;   using opengl_resource::opengl_resource;
        virtual ~ shader() {
           = ; glDeleteShader( id );
 =       }
  &nbs= p; };
    // Pass this&nb= sp;handle out to any structure/function:
    openg= l_handle sh =3D std::make_unique< sha= der >( glCreateShader( GL_VERTEX_SHADER ) );
= }

Over time, you can= migrate the local classes into a wrapper library. There is no commitment t= o either keeping everything local precluding reusability nor to a “fu= ll-blown” library (although I don’t see the risk in developing = such a thin library as you go).

There is a little = boilerplate, but it’s totally obvious how everything works. No room f= or error.

Destructors are (usually) implicitly noe= xcept, so using a non-noexcept function to define destructor functionality = loses a little safety. The traditional way on the other hand is essentially= perfect.

Virtual destructors are among the most widely-known idioms in exi= stence, and simply “doing things the old-fashioned way” would l= ikely have avoided this deleter confusion entirely.
=
I am not sure I understand how this applies to our discussio= n.

Every workable solution deserves = consideration. The apparent problem is merely that you believe classes shou= ld be declared in interface headers, but you want to have implementation cl= asses. C++ has always supported implementation classes. Besides local class= es, there are also unnamed namespaces. There is no need to go back to the b= ad old days of function pointers.

--

---
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>.
--Apple-Mail=_16AB018A-4F8E-4D70-B97D-3EDF0F926E84-- .