220 9502 <9c6e734b-dc8e-42db-8310-69f78b48a7f4@isocpp.org> article Path: news.gmane.org!not-for-mail From: vadim.petrochenkov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Feedback on N3949 - Scoped Resource - Generic RAII Wrapper for the Standard Library Date: Sun, 2 Mar 2014 22:07:39 -0800 (PST) Lines: 208 Approved: news@gmane.org Message-ID: <9c6e734b-dc8e-42db-8310-69f78b48a7f4@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3356_6347186.1393826859380" X-Trace: ger.gmane.org 1393826854 30611 80.91.229.3 (3 Mar 2014 06:07:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Mar 2014 06:07:34 +0000 (UTC) Cc: Andrew Sandoval , Peter Sommerlad To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJOZ3HVXIEBBLFY2CMAKGQEUUXDNQY@isocpp.org Mon Mar 03 07:07:44 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WKM2Q-000726-AF for gclcip-std-proposals@m.gmane.org; Mon, 03 Mar 2014 07:07:42 +0100 Original-Received: by mail-pa0-f71.google.com with SMTP id kq14sf9627112pab.10 for ; Sun, 02 Mar 2014 22:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=SNQYLjH3v59B/oXDvwUfX4bXlETKHjUrtj3WmvyP42U=; b=x8YSkxTCCbG96nS8zwut49Yo/l6ebXNm3FMAi4dytuScSdctbj6GDVrHPJNMMmsvpF dfXoSD8DRc59qA2fOFyf0cp6pFss5NzJlJEeuwUufN378J+0vzDdNjN3gfFaRgJ1WyLE a0eTOWv5IBgqgC3Inxe/Hd3B7KGCGevo51KUp17TWnBtjJcjmUbxCgejeh5KM7UZtS8G bk9h3cxXGeLDLl5Mo0X17UKw+PLKcKFkE7EVOfapaYOy3YwioU7dfDxbE1tIsE58kLIe g6UfL3lfG5o+3oaj3mX/68Ss1J/Vix7u0k3IZsXUIAW+cF18Jqj9gS3H9s+BaexoH9yD NFtw== 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:cc: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=SNQYLjH3v59B/oXDvwUfX4bXlETKHjUrtj3WmvyP42U=; b=jIjX2HIQzxSpzXoQVDDqznZqSyjOT9l4ZEE/qa03LNBlxJ/jJZzFTHwEUoaaIagcHc LCnttKuOQVoDNjrw1tsJG3lHTmxupkZ2vEPhPV6YIYoidwbXTRJ+S1pBWQhXmyt+zeJm CJyNZQNRBp1LfRPBBz3iesRtYRfE+nurS/yXnB7bOIVuxWEsUaExTiClD5F2D8gnDJ8A IIyfJrU5B4eD/t3qjziyMUDxI4j09Fh+xBb7XI+AAgcskcsPvbZxpDPB4kYHuT6oeuJ+ x0BQo6E6cdjss+uricl1/1XAOTmNsrIjiJaylhIIeLK4huiQXcSvi+XltIoMZZdEdI3D iN2Q== X-Gm-Message-State: ALoCoQnZ037+L+4wCgYpC39bWRZps9lTk3fuTUhLsG6fnwcbA/HYToVT0dcsy3ufFGcMwd2sUxMS X-Received: by 10.66.27.132 with SMTP id t4mr731676pag.6.1393826861047; Sun, 02 Mar 2014 22:07:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.93.161 with SMTP id d30ls1976133qge.4.gmail; Sun, 02 Mar 2014 22:07:40 -0800 (PST) X-Received: by 10.140.95.45 with SMTP id h42mr3363qge.22.1393826860272; Sun, 02 Mar 2014 22:07:40 -0800 (PST) In-Reply-To: X-Original-Sender: vadimpetrochenkov@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:9502 Archived-At: ------=_Part_3356_6347186.1393826859380 Content-Type: text/plain; charset=UTF-8 What do you think about this proposal and its future? Template parameter deduction for constructors It'd solve some present and future library inconveniences, including scope_guard and unique_resource, if ready in time. On Sunday, March 2, 2014 4:31:59 PM UTC+4, Ville Voutilainen wrote: > > 1) I find it odd that scope_guard_t is moveconstructible. QScopedPointer > isn't, boost::scoped_ptr isn't. If this type is designed to live in one > scope > and not move out of it, it should not be movable, since that allows > moving it into and out of scopes. If it is designed to be moved into > and out of scopes, I don't think its name is good. > > 2) minor nit: the deleted copy assignment operator for scope_guard_t > is void operator=(scope_guard_t const &)=delete;, the return type > is void, which is not the usual canonical form. The move assignment > operator isn't deleted, but it doesn't have to be since it will be > suppressed. > I would recommend explicitly deleting all copy/move operations > explicitly, so that implementations give better diagnostics. > > 3) I find the naming of the types and factory functions inconsistent > with the rest of the standard. This proposal uses scope_guard_t and > unique_resource_t as the types, and scope_guard and > unique_resource(_checked) > as the factory functions. I'd find it more consistent to have scope_guard > and unique_resource as the types and make_scope_guard and > make_unique_resource(_checked) as the factories. Sure, they are > longer to type, but they would be consistent. > > 4) unique_resource::operator-> is specified as > R operator->() const noexcept ; > Requires: > operator-> > is only available if > is_pointer::value && (is_class::value || is_union::value) > is true. > > I think this is a bit inconsistent with how library usually specifies > such SFINAE-conditional overloads. It's usually a Remark, so > I think this should be > > Requires: > operator-> > is only available if > is_pointer::value && (is_class::value || is_union::value) > is true. > > > Remarks: > This function shall not participate in overload resolution unless > is_pointer::value && (is_class::value || is_union::value) > is true. > > > We certainly don't want to have it as Requires, since usually violating > a Requires-clause results in undefined behavior. Same issue with > operator*, > > see below operator*() const noexcept; > > Requires: > This function is only available if > is_pointer::value is true. > > > Remarks: > This function shall not participate in overload resolution unless > is_pointer::value is true. > > > 5) unique_resource::get_deleter is specified as > const DELETER & get_deleter() const noexcept; > but the name of the template parameter is D, so > this should now be > > const D& get_deleter() const noexcept; > > > > I think the proposal is otherwise ok. :) > -- --- 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 email 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-proposals/. ------=_Part_3356_6347186.1393826859380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What do you think about this proposal and its future? = ;
On Sunday, March 2, 2014 4:= 31:59 PM UTC+4, Ville Voutilainen wrote:
1) I find it odd that scope_guard_t is moveconstructible. QScoped= Pointer
isn't, boost::scoped_ptr isn't. If this type is designed to live in one= scope
and not move out of it, it should not be movable, since that allows
moving it into and out of scopes. If it is designed to be moved into
and out of scopes, I don't think its name is good.

2) minor nit: the deleted copy assignment operator for scope_guard_t
is void operator=3D(scope_guard_t const &)=3Ddelete;, the return ty= pe
is void, which is not the usual canonical form.  The move assignme= nt
operator isn't deleted, but it doesn't have to be since it will be supp= ressed.
I would recommend explicitly deleting all copy/move operations
explicitly, so that implementations give better diagnostics.

3) I find the naming of the types and factory functions inconsistent
with the rest of the standard. This proposal uses scope_guard_t and
unique_resource_t as the types, and scope_guard and unique_resource(_ch= ecked)
as the factory functions. I'd find it more consistent to have scope_gua= rd
and unique_resource as the types and make_scope_guard and
make_unique_resource(_checked) as the factories. Sure, they are
longer to type, but they would be consistent.

4) unique_resource::operator-> is specified as
R operator->() const noexcept ;
Requires:
operator->
is only available if
is_pointer<R>::value && (is_class<R>::value || is_u= nion<R>::value)
is true.

I think this is a bit inconsistent with how library usually specifies
such SFINAE-conditional overloads. It's usually a Remark, so
I think this should be
<del>
Requires:
operator->
is only available if
is_pointer<R>::value && (is_class<R>::value || is_u= nion<R>::value)
is true.
</del>
<ins>
Remarks:
This function shall not participate in overload resolution unless
is_pointer<R>::value && (is_class<R>::value || is_u= nion<R>::value)
is true.
</ins>

We certainly don't want to have it as Requires, since usually violating
a Requires-clause results in undefined behavior. Same issue with
operator*,

see below operator*() const noexcept;
<del>
Requires:
This function is only available if
is_pointer<R>::value is true.
</del>
<ins>
Remarks:
This function shall not participate in overload resolution unless
is_pointer<R>::value is true.
</ins>

5) unique_resource::get_deleter is specified as
const DELETER & get_deleter() const noexcept;
but the name of the template parameter is D, so
this should now be

const D& get_deleter() const noexcept;



I think the proposal is otherwise ok. :)

--
 
---
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-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-proposals/<= /a>.
------=_Part_3356_6347186.1393826859380-- .