220 9493 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Feedback on N3949 - Scoped Resource - Generic RAII Wrapper for the Standard Library Date: Mon, 3 Mar 2014 02:08:14 +0800 Lines: 129 Approved: news@gmane.org Message-ID: References: <67F4693D-4473-4700-A60E-8C434D55E226@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_81527C4F-4DFC-41C0-9493-29580E16A543" X-Trace: ger.gmane.org 1393783700 32047 80.91.229.3 (2 Mar 2014 18:08:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Mar 2014 18:08:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBGPHZWMAKGQE6NKZFMQ@isocpp.org Sun Mar 02 19:08:28 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f198.google.com ([209.85.216.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WKAoO-0005ak-3H for gclcip-std-proposals@m.gmane.org; Sun, 02 Mar 2014 19:08:28 +0100 Original-Received: by mail-qc0-f198.google.com with SMTP id r5sf5112943qcx.5 for ; Sun, 02 Mar 2014 10:08:27 -0800 (PST) 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=lbexyaElf3wS6fJev/QURv/2SFj+kRrwniPqQbVs74o=; b=MRycfhYgZz8LwU/G9psHxoJdf6tePCq+SxGYGXm2JYiUft1c6JQ5WkgR7ECrkl1mD+ Z0D9QSX0hOLv5RxMqhe4wMdkcr6htmcUssFVNvsqI2p2sZUV2sSqC/dxX8MlotBmoPyS 1WtaRe4XdlWkUG0IjyeBjS3KE/bvHMmfVMEDI2+M8krVyWlpRdhOQoAsSyvoTAQ2rhmk ilVHEgYv0sHK8Jzh+8D9WN61t7I5W8NnUonpYVin/bat43MTIcAV28QRmqZFbZxFDiAe 9xVxmq8XT0TZm05PzATXxd+5R13N6679AnV0Cz6503ohojwdrgpexhDbP0po1hSkSdhK C4yQ== X-Gm-Message-State: ALoCoQnkSf4JzSWnx/n2UQtWqb0XIjgj8JSQTCO2CXtsAagLP8to/JlMuGR0GB5lLrV0UTtJcoRp X-Received: by 10.236.89.15 with SMTP id b15mr5901176yhf.13.1393783706905; Sun, 02 Mar 2014 10:08:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.102.7 with SMTP id fk7ls1523529igb.8.canary; Sun, 02 Mar 2014 10:08:25 -0800 (PST) X-Received: by 10.66.220.198 with SMTP id py6mr15022718pac.21.1393783705405; Sun, 02 Mar 2014 10:08:25 -0800 (PST) Original-Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [2607:f8b0:400e:c01::229]) by mx.google.com with ESMTPS id se8si8017513pbb.246.2014.03.02.10.08.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 10:08:25 -0800 (PST) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c01::229 as permitted sender) client-ip=2607:f8b0:400e:c01::229; Original-Received: by mail-pb0-f41.google.com with SMTP id jt11so2833144pbb.14 for ; Sun, 02 Mar 2014 10:08:25 -0800 (PST) X-Received: by 10.66.197.135 with SMTP id iu7mr677266pac.149.1393783705271; Sun, 02 Mar 2014 10:08:25 -0800 (PST) Original-Received: from [172.20.10.2] ([121.54.54.55]) by mx.google.com with ESMTPSA id g6sm66481789pat.2.2014.03.02.10.08.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 10:08:24 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1874) 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:c01::229 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:9493 Archived-At: --Apple-Mail=_81527C4F-4DFC-41C0-9493-29580E16A543 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On Mar 3, 2014, at 1:47 AM, Ville Voutilainen = wrote: > Well, good point, but I now realize that it's not an artifact of having t= o > deduce the type, but an artifact of having to be able to return the type > from a factory type. Well, the factory only exists to perform deduction. But moving on... > Urgh. So, move construction does not need to be allowed, if auto && is required. = This is the better design choice. For comparison, the original scope_guard = required use of const & to get around C++03 limitations of initialization a= nd persistence in the absence of auto. It's also the only way a guard can work without that internal Boolean flag,= which is necessary to make the usually-elided move constructor do the righ= t thing. >> 3) I find the naming of the types and factory functions inconsistent >> with the rest of the standard. >> The proposal notes that this is because the guard isn't supposed to be >> treated as an object. >=20 > Well, unique_resource most certainly _will_ be treated as an object. > And not everybody will use auto with it. People will store unique_resourc= es > in containers. Agreed. Actually the given justification is "because they actually do not a= llocate any resources, like std::make_unique or std::make_shared do." But t= here are other non-allocating factory functions like make_tuple. My brain q= uietly substituted "object" for "resource." >> What's the point of the restriction anyway? R will seldom if ever be >> anything besides a pointer or class, and the operator-> definition is >> well-formed for any copyable R. (Non-copyable objects are always classes >> anyway.) >=20 > operator-> is not valid for a resource that holds an int, for example. That wouldn't be much of a resource. Anyway, as I said, the member declarat= ion, and function body, are still valid. GCC and Clang -pedantic don't warn= about such a declaration. It's useless, but harmless. (On the other hand, = we've already had a bug with the SFINAE here ;v) .) --=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=_81527C4F-4DFC-41C0-9493-29580E16A543 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Mar 3= , 2014, at 1:47 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

Well, good point, but = I now realize that it's not an artifact of having to
deduce the type, bu= t an artifact of having to be able to return the type
from a factory typ= e.

Well, the factory only exists to perform= deduction. But moving on…

Urgh.<= br>

So, move construction does not need to = be allowed, if auto && is required. T= his is the better design choice. For comparison, the original scope_guard required use of co= nst & to get around C++03 limitations of initialization and= persistence in the absence of auto.

It’s also the only way a guard can work without that= internal Boolean flag, which is necessary to make the usually-elided move = constructor do the right thing.

3) I find the naming of the types and factory functions i= nconsistent
with the rest of the standard.
The proposal notes that th= is is because the guard isn't supposed to be
treated as an object.

Well, unique_resource most certainly _will_ be treated as an= object.
And not everybody will use auto with it. People will store uniq= ue_resources
in containers.

Agreed. Actua= lly the given justification is "because they actually do not allocate = any resources, like std::make_unique&n= bsp;or std::make_shared do.” But t= here are other non-allocating factory functions like make_tuple. My brain quietly substituted “object” for &= ldquo;resource.”

What's the point of the restriction anyway? R will seldom if = ever be
anything besides a pointer or= class, and the operator-> definition is
well-formed for any copyable= R. (Non-copyable objects are always classes
anyway.)
operator-> is not valid for a resource that holds an int, for example.=

That wouldn’t be much of a resource. = Anyway, as I said, the member declaration, and function body, are still val= id. GCC and Clang -pedantic don’t warn = about such a declaration. It’s useless, but harmless. (On the other h= and, we’ve already had a bug with the SFINAE here ;v) .)

--

---
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=_81527C4F-4DFC-41C0-9493-29580E16A543-- .