Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2013-10-02 00:37:56
I agree that non-null smart pointers are a useful facility. That said I do
have some additional thoughts:
On Tue, Oct 1, 2013 at 3:54 PM, Luke Bradford <lukebradford01_at_[hidden]>wrote:
> (1) It doesn't have reset() with no arguments, doesn't have a default
> constructor, and doesn't have implicit conversion to bool (which would
> always be true.)
Not having a default constructor seems unnecessary to me. Why not just have
the default constructor dynamically allocate a default constructed object?
Similarly, for consistency with other smart pointers, having a conversion
to bool would be useful and makes transition to the type simpler. IMO we
should keep a similar interface where possible, even if the result is
(2) It throws an exception whenever there's an attempt to make it empty,
> i.e. in constructors, reset, assignment, and swap.
I don't think an exception here is proper. Initializing the object by
passing a null pointer should be UB since it is a clear violation of the
constructor's assumed precondition (don't pass a null pointer), and similar
for other operations that would produce such a "null" non-null object.
Rather, these should simply be asserts.
For convenience, it's implicitly convertible to shared_ptr, and I have all
> of shared_ptr's templated operators implemented with possible combinations
> of shared_ptr and shared_ptr_nonnull. Usually it can be used just by
> changing the type of a shared_ptr.
I'm fine with this except for the implicitly convertible to shared_ptr
part. What's wrong with explicit conversion here?
-- -Matt Calabrese
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk