Re: [Defect Report] shared_ptr and nullptr
Greg Herlihy ha scritto:
On 11/2/07 8:37 AM, in article UbDWi.161370$U01.1150275@twister1.libero=
..it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
Therefore the
expression that must be well-formed and that shall be called if an
exception is thrown should follow accordingly. This would make a
difference, for example, with this deleter:
struct naive_deleter
{
template <class T>
void operator()(T* ptr) const { delete ptr; }
};
I am a somewhat embarrassed to be this na=C3=AFve, but I must admit tha=
t I just
don't see a problem with naive_deleter. Could you please elaborate? (We=
ll,
there is a potential problem in that naive_deleter().(nullptr) will not
compile - because no type can be deduced for "T". But presumably shared=
_ptr
would avoid this issue by calling naive_deleter().<T*>(nullptr) explici=
tly.)
Your "potential problem" is precisely the point. Suppose you write this:
struct A {};
struct B : A {};
shared_ptr<A> p1(new A, naive_deleter()); // #1
shared_ptr<A> p2(new B, naive_deleter()); // #2
shared_ptr<A> p3(nullptr, naive_deleter()); // #3
#1 will eventually call naive_deleter::operator(A*)
#2 will eventually call naive_deleter::operator(B*)
Assuming the OP proposal, #3 will fail because T cannot be deduced while
instantiating naive_deleter::operator(T*).
Now the question is: do we actually want that or wouldn't it be
preferable to make #3 call naive_deleter::operator(A*)? Now that I think
about it in these terms, I have to admit that I can't decide.
BTW, shared_ptr can *not* call naive_deleter().<T*>(nullptr) explicitly,
because it can not know in advance that operator() is a template.
However it might call naive_deleter()((T*)nullptr)).
2) I actually like the "get() == nullptr" in the postcondition, bu=
t I
think we should keep a consistent style throughout all the clause. So
either we use the standard "get() == 0" here or we replace every "=
get()
== 0" to "get() == nullptr" all over the place. (For what it's=
worth, my
preference goes to the second option.)
I think it is a good idea to replace 0 with nullptr wherever appropriat=
e. I
think that nullptr works best as a "universally-compatible" null pointe=
r
constant. The problem with the proposed nullptr_t overloads in shared_p=
tr's
interface - is that nullptr_t is not appearing in the context of any
specific pointer type, but has instead become a type unto itself. Yet
shared_ptr never cared to support initialization with the old "0" null
pointer constant (and still would not support "0" even with these chang=
es).
So why should shared_ptr now implement an entire set of routines - just
because "0" has been renamed?
Because it has not just been renamed. nullptr is not just a special name
for 0, the former is a pointer (with an unspecified pointee type), while
the latter is an integer (that happens to be convertible to a pointer
type in some contexts).
One explanation might be that there is something "special" about nullpt=
r
that requires such special treatment. But a C++ programmer should think=
of
nullptr_t as some new, special type - one that will require adding enti=
re
sets of routines just to support it. Instead a C++ programmer should vi=
ew
"nullptr" as the null pointer constant with a more sensible name (and
slightly better behavior) than the old null pointer constant. But other=
wise
there is not all that much difference between the two.
So it seems to me that - instead of having shared_ptr declare all of th=
ese
nullptr_t overloads that elevate nullptr' status - shared_ptr should do=
the
opposite: treat any nullptr argument as if it were (T*) 0 argument inst=
ead.
In other words, shared_ptr should treat nullptr just as it treats any o=
ther
stored pointer value. So all that would need to be added to the Standar=
d
would be a paragraph to that effect. For example:
"An implementation shall ensure (by unspecified means) that a nullptr
argument passed as a pointer parameter to a shared_ptr<T> method - will
produce the same observable behavior as if a (T*)nullptr argument had b=
een
passed in its place. [Note: an implementation might overload existing
shared_ptr methods that accept a template pointer type parameter with a=
n
method that accepts T* parameter instead. This overload would then forw=
ard
its calls to the usual method while specifying T* as the type of the nu=
llptr
argument.]"
The question is if
shared_ptr<A> ptr(nullptr);
should be equivalent to
shared_ptr<A> ptr((A*)0); // #1
or rather to
shared_ptr<A> ptr; // #2
This isn't trivial, because #1 might need to allocate heap memory for
the deleter and therefore might throw, while #2 won't. My personal
preference definitely goes to #2. Moreover, constructor #1 is and shall
remain explicit, yet I believe that the implicit conversion from nullptr
should be allowed.
If you don't like the extra signatures, we could stress the equivalence
by changing the signature of the default constructor instead, thus
replacing:
shared_ptr();
with
shared_ptr(nullptr_t = nullptr);
As for the two-params and three-params constructors, the argument
doesn't hold, because the deleter must be allocated anyway. I still
haven't made up my mind on those.
As for the three reset() signatures with parameters, they are defined in
terms of the constructors, so instead of adding new signatures, we could
simply replace the "old" ones with:
template<class Y> void reset(Y p);
template<class Y, class D> void reset(Y p, D d);
template<class Y, class D, class A> void reset(Y p, D d, A a);
where the type of the first parameter is Y instead of Y*. However, given
that the requirements on the deleter type are going to be reduced from
CopyConstructible to MoveConstructible and that passing deleter and
allocator by value might require an unneeded copy, I would go even
further and replace all four signatures (including the one without
parameters) with just one:
template<class... Args> void reset(Args&&... args);
defined to have the same effect as:
shared_ptr(std::forward<Args>(args)...).swap(*this);
Just my opinion,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]