Re: [Defect Report] shared_ptr and nullptr
On 11/2/07 8:37 AM, in article UbDWi.161370$U01.1150275@twister1.libero.it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
Just a couple more remarks:
Joe Gottman ha scritto:
template <class D> shared_ptr(nullptr_t, D d);
template <class D, class A> shared_ptr<nullptr_t, D d, A a);
Requires: D shall be CopyConstructible. The copy constructor and
destructor of D shall not throw exceptions. The expression
d(nullptr) shall be well-formed, shall have well defined behavior,
and shall not throw exceptions. A shall be an allocator (20.1.2).
The copy constructor and destructor of A shall not throw
exceptions.
Effects: Constructs a shared_ptr object that owns deleter d. The
second constructor shall use a copy of a to allocate memory for
internal use.
Postconditions: use_count() == 1 and get() == nullptr.
Throws: bad_alloc, or an implementation-defined exception when a
resource other than memory could not be obtained.
Exception safety: If an exception is thrown, d(nullptr) is called.
1) As the value of the (null) pointer is going to be eventually
converted to type T*, the expression that is going to be called in the
destructor will be d((T*)nullptr) rather than d(nullptr).
There is nothing in the proposed shared_ptr interface that suggests that a
nullptr initializer is ever converted to any particular pointer type. After
all, becauser nullptr has its own overloaded constructor, no type deduction
is performed with the nullptr (as is performed with other pointer
arguments), so it is logical to conclude that nullptr is just a nullptr_t
type.
In fact, one reason that I suggested a shared_ptr(T*) constructor overload -
was precisely to "convert" a nullptr argument to a T* null pointer constant.
Because once this conversion is performed, shared_ptr can treat nullptr just
as it treats any other stored pointer value.
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?ve, but I must admit that I just
don't see a problem with naive_deleter. Could you please elaborate? (Well,
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) explicitly.)
2) I actually like the "get() == nullptr" in the postcondition, but 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 appropriate. I
think that nullptr works best as a "universally-compatible" null pointer
constant. The problem with the proposed nullptr_t overloads in shared_ptr'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 changes).
So why should shared_ptr now implement an entire set of routines - just
because "0" has been renamed?
One explanation might be that there is something "special" about nullptr
that requires such special treatment. But a C++ programmer should think of
nullptr_t as some new, special type - one that will require adding entire
sets of routines just to support it. Instead a C++ programmer should view
"nullptr" as the null pointer constant with a more sensible name (and
slightly better behavior) than the old null pointer constant. But otherwise
there is not all that much difference between the two.
So it seems to me that - instead of having shared_ptr declare all of these
nullptr_t overloads that elevate nullptr' status - shared_ptr should do the
opposite: treat any nullptr argument as if it were (T*) 0 argument instead.
In other words, shared_ptr should treat nullptr just as it treats any other
stored pointer value. So all that would need to be added to the Standard
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 been
passed in its place. [Note: an implementation might overload existing
shared_ptr methods that accept a template pointer type parameter with an
method that accepts T* parameter instead. This overload would then forward
its calls to the usual method while specifying T* as the type of the nullptr
argument.]"
Greg
---
[ 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 ]