Subject: Re: [boost] [RFC] unique_val (handles, IDs, descriptors...)
From: Miguel Ojeda (miguel.ojeda.sandonis_at_[hidden])
Date: 2018-02-14 22:39:29
On Wed, Feb 14, 2018 at 10:48 PM, Nevin Liber via Boost
> On Wed, Feb 14, 2018 at 3:18 PM, Miguel Ojeda via Boost <
> boost_at_[hidden]> wrote:
> IMO, such a class is definitely useful.
Thanks *a lot* for the almost instantaneous review! :)
> Design concerns:
> - unique_val should be copyable if T is copyable. Whether or not a type
> which aggregates this is copyable is an orthogonal, separate concern from
> what the moved-from state should be. If you go this route, unique_val is
> the wrong name.
As Steven mentions, it cannot be copyable since it is meant to hold
values where you need to perform an action on deletion once per value,
i.e. I meant "unique" here as the same as "unique_ptr" means: only one
"owner" is supposed to hold a given value.
> - Instead of providing operator bool(), why not provide operator T&()
> and operator T const&()?
Hum, that could be interesting, not sure of all the implications, though.
> - What about comparisons of the form: unique_val<T, a> op unique_val<T,
> - What about comparisons of the form: unique_val<T> op T (as well as T
> op unique_val<T>)?
Indeed, I suggest the second ones in the Rationale as possible
extensions, I think they make quite a lot of sense. I thought about
the first ones, but I don't think they are that useful in practise,
since when you are using the unique_val, you already know what your
"invalid" or "moved-from" or "default" value has to be, so you will
not be using different ones (i.e. I don't think in practise
unique_val<T, x> and unique_val<T, y> where x != y is a common case).
> - Propagate noexcept correctly, as it is dependent on the underlying
I thought that, given that T has to be a type suitable for the default
(which itself is a non-type template parameter), it couldn't be
anything throwing exceptions -- but I may be wrong here; please let me
> - Propagate constexpr correctly (for instance, your default constructor
> should be constexpr).
Indeed, probably a few constexpr's are missing. I only added the
obvious get_default() one since I am not sure what are the best
practices for writing them for C++11, C++14 and C++17 at the same time
without breaking something. Since it was optional, I left it at that
for the moment.
Thanks a lot again!
> Nevin ":-)" Liber <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
> +1-847-691-1404 <(847)%20691-1404>
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk