Btw, I neglected to include Ion's suggestion:

...

If we can define the pointer type via deleter::pointer or similar (with default T*) that would be even better.

which I think is a good one. Update on the way...

Can we add that also for unique_ptr Reference Implementation? http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html Other smart pointers can benefit from a templatized pointer type also, like intrusive_ptr: template<class T, class VoidPointer = void *> class intrusive_ptr; See: http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/shmem/shmem_smar... With Boost 1.34 boost::pointer_to_other<> and generalized get_pointer() utilities intrusive pointer could support different pointer types. I'm also seeing if a shared memory/memory mapped file shared_ptr<> is possible using templatized pointers, but the lack of polymorphic operations in shared memory would require an additional deleter template parameter and an additional allocator template parameter to allocate the reference count. Too much? With so many smart pointers, I'm certainly confused. What's the difference between unique_ptr: http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html and move_ptr: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#move_ptr%20Exa... Do we need scoped_ptr in future C++ standard if unique_ptr has all needed operations? Or it's too dangerous for a scoped resource pattern because of the release() operation? Ion

On Mar 12, 2006, at 5:22 AM, Peter Dimov wrote:

...

How do you say: I don't care about the copyright? Copy it, trash it, do include my name or don't, I don't care. It's only here for your amusement. I'm attempting to post anonymously.

"I, Howard Hinnant, hereby place this code in the public domain"

Thanks Peter, done. On Mar 12, 2006, at 4:54 AM, Ion Gaztañaga wrote:

...

Btw, I neglected to include Ion's suggestion:

...

If we can define the pointer type via deleter::pointer or similar (with default T*) that would be even better.

which I think is a good one. Update on the way...

Can we add that also for unique_ptr Reference Implementation?

http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html

Done. But I did it differently then my first attempt yesterday. Yesterday I had: template <class T, class D = ...> class unique_ptr { public: ... typedef typename D::pointer; }; But this disallows handy deleters such as: struct my_deleter { // no way to define pointer typedef! template <class T> void operator()(T* p) {...} }; which I found distressing. So now both the reference and emulation implementations will use D::pointer only if it exists in D, otherwise T* is used. This is not only more flexible, but also more convenient. You can forget about defining the pointer typedef in your deleter unless you really care about it. If you get the chance Ion, see how this emulated unique_ptr stands up to your shared memory torture test (and thanks). :-)

With so many smart pointers, I'm certainly confused. What's the difference between unique_ptr:

http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html

and move_ptr:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/ n1377.htm#move_ptr%20Example

unique_ptr is essentially a renaming of move_ptr (in addition to minor refinements such as the deleter policy and array handling). A couple of years ago I became disenchanted with the name move_ptr because several smart pointers could have a move constructor that differed from its copy constructor (e.g. clone_ptr). So I searched for a new name which stressed the pointer's ownership behavior instead of simply showcasing move semantics.

Do we need scoped_ptr in future C++ standard if unique_ptr has all needed operations? Or it's too dangerous for a scoped resource pattern because of the release() operation?

I'll let others address (and possibly propose) that one. I've personally never really used scoped_ptr and so would be the wrong champion for it. -Howard