Topic: Feedback on N3949 - Scoped Resource - Generic RAII
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 14:31:59 +0200
Raw View
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<R>::value && (is_class<R>::value || is_union<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_union<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_union<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 "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/.
.