Quote:Original post by Zahlman

Quote:Original post by Emmanuel Deloget
Regarding auto_ptr<>, I don't look it as an evil class. It has its use - if you don't need the can-share semantics of shared_ptr, auto_ptr works just fine.

Or if you need to put it in a container.

Quote:Original post by Zahlman
Why is there no standard smart pointer (or did I overlook something?) with "copy the pointed-at thing" semantics? I find myself hand-rolling it all the time. (Of course, if the copy is expensive or impossible, then shared_ptrs become necessary, yes.)

Quote:Original post by Emmanuel Deloget

Quote:Original post by Zahlman
Why is there no standard smart pointer (or did I overlook something?) with "copy the pointed-at thing" semantics? I find myself hand-rolling it all the time. (Of course, if the copy is expensive or impossible, then shared_ptrs become necessary, yes.)

You'll have to make sure that the object you want to copy is CopyConstructible - if it's not, then you'll have to fallback to another solution, which means that your smart pointer will behave differently depending on the object it encapsulates - that would be quite difficult to use (even if the implementation part is not that hard - if you use type traits). This is, IMHO, a no-no for a standard library, whose effects has to be known and consistent.

Regards,

Quote:Original post by jpetrie

Quote:
Why is there no standard smart pointer (or did I overlook something?) with "copy the pointed-at thing" semantics? I find myself hand-rolling it all the time. (Of course, if the copy is expensive or impossible, then shared_ptrs become necessary, yes.)

Perhaps I'm misunderstanding the functionality you want, but why not just use a non-pointer if you need operator= to "copy the thing?"

Quote:Fair point!

But "copy the thing that is pointed to" pointers alone won't be enough for that to work in general, you'd need a standard polymorphic clone of some sort, or a special container, or a number of other extra enhancements.

// this version provides fast acess to the stored ptr at the cost of slightly// more memory usage, it is however possible to reduce memory usage by// adding another layer of indirection when accessing the stored ptr// used to maintain type information for copyingtemplate<typename BaseType>struct copy_ptr_storage{    virtual BaseType* copy(BaseType*) = 0;    virtual copy_ptr_storage<BaseType>* clone() = 0;};// stores the actual type infotemplate<typename BaseType, typename T>struct copy_ptr_impl : copy_ptr_storage{    BaseType* copy(BaseType* p)    {        return new new T(*static_cast<T*>(p));    }    copy_ptr_storage<BaseType>* clone()    {        return new copy_ptr_impl<BaseType, T>();    }};// the ptrstruct copy_ptr<typename BaseType>{    template<typename T>    copy_ptr(T* ptr):    type_ptr(new copy_ptr_impl<T>()),    base_ptr(ptr)    { }    copy_ptr(const copy_ptr<BaseType>& rhs):    type_ptr(rhs.type_ptr->clone()),    base_ptr(rhs.type_ptr->copy(rhs.base_ptr));    {    }    copy_ptr<BaseType&> operator=(const copy_ptr<BaseType>& rhs)    {        delete base_ptr;        base_ptr = rhs.type_ptr->copy(rhs.base_ptr);        delete type_ptr;        type_ptr = rhs.type_ptr->clone();    }    BasePtr& operator*()    {        return *base_ptr;    }    BaseType* oprator->()    {        return base_ptr;    }    ~copy_ptr()    {         delete type_ptr;        delete base_ptr;    }private:    copy_ptr_storage* type_ptr;    BaseType* base_ptr;};

Quote:Original post by Zahlman

Quote:Original post by jpetrie
Perhaps I'm misunderstanding the functionality you want, but why not just use a non-pointer if you need operator= to "copy the thing?"

Polymorphism, Pimpls, virtual clone idiom etc. (If you can standardize the name of the clone() function, it should be possible to use SFINAE introspection to make use of it?)