Re: ANN: AutoNewPtr (oh yes, yet another smartpointer)
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
[snip]
I just coded this up, and hopefully by mentioning it here I'll get some
useful feedback, like, bugs, shortcomings, improvements...
http://code.google.com/p/alfps/source/browse/trunk/alfs/pointers/AutoNewPtr.hpp
[snip]
When I did something along these lines (a smart pointer that also
encapsulates allocation), I made a few different choices. Just for
comparison:
a) Instead of a custom deleter
Well, just so as not to mislead readers, there isn't a dynamic custom
deleter, only possible specialization of std::default_delete.
, I templated the class on an allocator and
allowed for allocator objects to be passed upon construction. The
allocator is in charge of allocation and deallocation of the pointee.
Yes. I haven't addressed the issue of customized creation. Not sure
if it's really useful, considering that raw allocation can be
customized via operator new and operator delete?
With shared_ptr a custom per-instance deleter is necessary because the
pointee is supplied externally, so could come from anywhere, e.g. from
some factory function, or being a pointer to literal string in one
invocation and a pointer to dynamically allocated string in other
invocation. Even though, for pointer to literal, shared_ptr doesn't
really support "no deletion" because it adds a lot of overhead.
I think, the custom deleter does not only serve as a customization hook. In
part it is a trick that enables shared_ptr<T> to allow for incomplete T
(more precisely, only at the point of construction of a shared_ptr<T>
object, the type T needs to be complete). I
Yes, that too.
That
extreme shared_ptr overhead for the simplest case is one reason why I
think it's a shame that intrusive_ptr is not in the C++0x proposal.
And as illustrated by CheckingPtr and AutoNewPtr, intrusive_ptr is
really great in general for building one's own smart shared pointers.
I think, if I had to choose between shared_ptr or intrusive_ptr in the
standard, I'd choose the latter (but best, of course, to have both!).
Because the most relevant functionality of shared_ptr is easily
implemented in terms of intrusive_ptr, whereas the opposite is
practically impossible: one can't get rid of shared_ptr inefficiency.
If I recall correctly, intrusive_ptr<T> requires T to be complete.
But that's irrelevant when intrusive_ptr is used to implement the
delete invoker / reference counting for a smart pointer.
The smart pointer that internally uses intrusive_ptr can still support
incomplete type T, e.g. for PIMPL idiom usage.
As another example, intrusive_ptr requires that T implements reference
counting, but again, that requirement does not spill over to a smart
pointer that internally uses intrusive_ptr for its automatic deletion.
However, by and large I agree: I found intrusive reference counting
sufficient for almost all of my needs.
[snip]
d) I more or less followed tr1::shared_ptr with regard to the interface
(other than the allocator stuff). Thus, dynamic casting is provided by
means of free standing friend functions.
Why?
Well, of course these free standing friends are also called
dynamic_something_cast to increase grep-ability. I can just grep for
dynamic*cast to find all the conversions in question.
Also, I like to follow naming conventions and interface design of the
standard where applicable. I feel that it makes my codebase more uniform
and easier to read.
On a related note, are your
pointers covariant with respect to derived classes? i.e., if D derives
from
T, is there an implicit conversion from smart_pointer<D> to
smart_pointer<T>? I did not see the trickery I usually use for that in
your
code (and I would not even know how to make that work with the wrappers
that you create to make the deletion notifications work).
Yes, there is covariant conversion. It's quite simple; I don't
understand what you mean by "trickery". All conversions are done by
constructors, so in CheckingPtr that conversion is performed by
// Logical "implicit upcast".
template< typename U >
CheckingPtr( CheckingPtr<U> const& other )
: myPtr( other.myPtr )
, myDeleter( other.myDeleter )
{}
Here the static type checking is imposed by the initialization of
myPtr with other.myPtr.
My bad. I was blind.
Aren't we all... :-)
I haven't implemented static_cast-like functionality for going the
other way, but there is dynamic_cast-like functionality for that (IMHO
static_cast-like functionality would, at this level, just be a risky
optimization, and providing it could be evil premature optimization).
I provide the static_cast family. With library components, there is no such
thing as premature optimization since you cannot benchmark applications yet
to be written. In my opinion, it is the job of the client code programmer
to make wise choices; it is not the job of the library implementor to
decide which performance priorities client code should have.
Oh, I don't think that argument holds. If so then we wouldn't use
private: and such to restrict client code... There is a trade-off.
e) Instead of a deletion notification framework that is pointee based, I
experimented with a pointer that has a kill() member function to
delete the
pointee and notify all interested parties.
One reason that I chose to just /detect/ pointee destruction is that
if the pointee is an object in some GUI framework, you can't easily
get the GUI framework to call a kill() function: it will just destroy
the pointee (e.g. when parent window closes or user closes a window).
Another reason is that for self-destruction as an alternative to
zombie state, e.g. for a file object, with a kill() function the
pointee would have to know about the smart pointer and sort of "reach
up" to the smart pointer's kill() function to destroy itself.
As it is, with just detection of destruction, it's all largely
transparent.
That's an interesting point. I don't do GUIs (or any other event driven
software). I guess that is why it never ocured to me.
Yes, and using this technique for files etc. is not common, in fact
I've never seen it done except experimentally by myself.
And I think the reason for that is not that it's ungood idea. On the
contrary I think (still! :-) but haven't yet really tried it out)
that it's a great idea. I think the reason it's not done is that so
far the basic infra-structure for the technique, namely pointers like
CheckingPtr and AutoNewPtr, has not been available, and so the cost of
doing self-destruction instead of zombie-state has been very high.
Now, if my pointers should be successful, and/or others implement such
pointers, with the infra-structure in place I think the no-zombies way
of programming could start to take off -- perhaps, hopefully...
BTW: I also used encapsulated construction among, to implement a
garbage-collecting smart pointer that would work transparently with
cycles.
Unfortunately, there is a considerable overhead.
That sounds interesting. I know there is a proposal for helping out
with collection of cycles. It sounds like your approach is/was quite
different (even though I don't recollect the details of the proposal)?
It's actually not all that hard. For concreteness, let us call that smart
pointer gc_ptr<T>. Upon construction of a gc_ptr<T> object ptr, space for
the pointee is allocated and ptr knows which memory region it owns. In
particular, it can register in a static database. Now, the pointee is
constructed. If T has member objects of type gc_ptr<X>, those will be
constructed in the process. Each of those will check where it resides in
memory and then notify ptr that a gc_ptr object has been constructed in the
memory region owned by ptr. This information is stored and used for a
simple garbage collector. Finally, you can remove the region from the
static database to save space.
Huh, I'm not sure I understood that.
It sounds like a strict hierarchy.
But with a strict hierarchy you don't have cycles?
I haven't addressed the issue of cycles at all.
A first step in that address would be something equivalent to
boost::weak_ptr, but, I haven't yet needed such equivalent... :-)
Same here :-)
Interesting.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?