delete operator on smart pointers.

Discussion in 'C++' started by =?iso-8859-1?q?Ernesto_Basc=F3n?=, Jan 6, 2007.

  1. I am implementing my custom smart pointer:

    template <typename T>
    class MySmartPtr
    {
    public:
    MySmartPtr(T* aPointer)
    {
    mPointer = aPointer;
    }

    inline T* operator->() const {return mPointer; }

    private:
    T* mPointer;
    };


    It could be used in this way:

    MySmartPtr<A> obj = new A();
    obj->Method1();
    int value = obj->Method2();

    The operator-> overload allows accessing the A methods as they are
    accessed via a common pointer.

    I want to allow the final user call the delete operator as in a common
    pointer when he wants to explicitly remove the pointer:

    delete obj;


    There is a way I could implement an overload of the delete pointer in
    my MySmartPtr<T> or there is some workaround on this?

    Thanks in advance,


    ernesto
    =?iso-8859-1?q?Ernesto_Basc=F3n?=, Jan 6, 2007
    #1
    1. Advertising

  2. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Heinz Ozwirk Guest

    "Ernesto Bascón" <> schrieb im Newsbeitrag
    news:...
    >I am implementing my custom smart pointer:
    >
    > template <typename T>
    > class MySmartPtr
    > {
    > public:
    > MySmartPtr(T* aPointer)
    > {
    > mPointer = aPointer;
    > }
    >
    > inline T* operator->() const {return mPointer; }
    >
    > private:
    > T* mPointer;
    > };
    >
    >
    > It could be used in this way:
    >
    > MySmartPtr<A> obj = new A();
    > obj->Method1();
    > int value = obj->Method2();
    >
    > The operator-> overload allows accessing the A methods as they are
    > accessed via a common pointer.
    >
    > I want to allow the final user call the delete operator as in a common
    > pointer when he wants to explicitly remove the pointer:
    >
    > delete obj;
    >
    >
    > There is a way I could implement an overload of the delete pointer in
    > my MySmartPtr<T> or there is some workaround on this?


    To make your smart pointer really smart, it should also implement a default
    constructor, a copy constructor and an assignment operator (actually two, a
    copy assignment operator and one to assign raw pointers). If they are
    implemented correctly, you could just write

    obj = 0; // or NULL

    to free whatever the smartpointer owned before.

    HTH
    Heinz
    Heinz Ozwirk, Jan 7, 2007
    #2
    1. Advertising

  3. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Paul Hosre Guest

    Ernesto Bascón wrote:
    > I am implementing my custom smart pointer:
    >
    > template <typename T>
    > class MySmartPtr
    > {
    > public:
    > MySmartPtr(T* aPointer)
    > {
    > mPointer = aPointer;
    > }
    >
    > inline T* operator->() const {return mPointer; }
    >
    > private:
    > T* mPointer;
    > };
    >
    >
    > It could be used in this way:
    >
    > MySmartPtr<A> obj = new A();
    > obj->Method1();
    > int value = obj->Method2();
    >
    > The operator-> overload allows accessing the A methods as they are
    > accessed via a common pointer.
    >
    > I want to allow the final user call the delete operator as in a common
    > pointer when he wants to explicitly remove the pointer:
    >
    > delete obj;
    >
    >
    > There is a way I could implement an overload of the delete pointer in
    > my MySmartPtr<T> or there is some workaround on this?
    >
    > Thanks in advance,
    >
    >
    > ernesto


    did you try debuggig and watch what object is actually in use then
    delete it directly?
    Paul Hosre, Jan 7, 2007
    #3
  4. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Paul Hosre Guest

    Heinz Ozwirk wrote:

    >
    > To make your smart pointer really smart, it should also implement a default
    > constructor, a copy constructor and an assignment operator (actually two, a
    > copy assignment operator and one to assign raw pointers). If they are
    > implemented correctly, you could just write
    >
    > obj = 0; // or NULL
    >
    > to free whatever the smartpointer owned before.
    >
    > HTH
    > Heinz

    That's an elegant point!
    I watched my google search carefully with my pair of glasses and I
    turned out to have the same incorrect thought with others. hehe
    Paul Hosre, Jan 7, 2007
    #4
  5. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Paul Hosre Guest

    Heinz Ozwirk wrote:

    >
    > To make your smart pointer really smart, it should also implement a default
    > constructor, a copy constructor and an assignment operator (actually two, a
    > copy assignment operator and one to assign raw pointers). If they are
    > implemented correctly, you could just write
    >
    > obj = 0; // or NULL
    >
    > to free whatever the smartpointer owned before.
    >
    > HTH
    > Heinz

    That's an elegant point!
    I watched my google search carefully with my pair of glasses and I
    turned out to have the same incorrect thought with others. heh
    Paul Hosre, Jan 7, 2007
    #5
  6. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Grizlyk Guest

    Ernesto Bascón wrote:

    > MySmartPtr(T* aPointer){ mPointer = aPointer; }

    Better do
    MySmartPtr( T *const aPointer=0 )throw():mPointer(aPointer){ }

    > MySmartPtr<A> obj = new A();

    It can produce sequence

    MySmartPtr<A>() + MySmartPtr<A>() + MySmartPtr<A>(const MySmartPtr<A>&)
    or MySmartPtr<A>::eek:perator = (const MySmartPtr<A>&)

    Better do
    MySmartPtr<A> obj (new A() );

    > obj->Method1();

    Define both
    ? T* operator-> () ? throw(){ return mPointer; }
    ? T& operator* () ? throw(){ return *mPointer; }
    be shure "const" instead "?" is correct for MySmartPtr behaviour

    > int value = obj->Method2();


    > I want to allow the final user call the delete operator as in a common
    > pointer when he wants to explicitly remove the pointer:
    >
    > delete obj;


    Try do
    public:
    operator T* ()throw(){ T *const tmp=mPointer; mPointer=0; return
    tmp; }
    ~MySmartPtr()throw(){ delete mPointer; mPointer=0; }

    Define (if you can not dynamic copy like this, else as need)
    private:
    MySmartPtr(const MySmartPtr&)throw():mPointer(0){ exit(1); }
    void operator= (const MySmartPtr&)throw(){ exit(1); }
    Grizlyk, Jan 12, 2007
    #6
  7. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Grizlyk Guest

    Grizlyk wrote:

    > Define (if you can not dynamic copy like this, else as need)
    > private:
    > MySmartPtr(const MySmartPtr&)throw():mPointer(0){ exit(1); }
    > void operator= (const MySmartPtr&)throw(){ exit(1); }


    Yes, and yet
    public:
    T* operator= (T *const aPointer)throw() { delete mPointer;
    mPointer=aPointer; }
    Grizlyk, Jan 12, 2007
    #7
  8. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    mlimber Guest

    Ernesto Bascón wrote:
    > I am implementing my custom smart pointer:
    >
    > template <typename T>
    > class MySmartPtr
    > {
    > public:
    > MySmartPtr(T* aPointer)
    > {
    > mPointer = aPointer;
    > }
    >
    > inline T* operator->() const {return mPointer; }
    >
    > private:
    > T* mPointer;
    > };
    >
    >
    > It could be used in this way:
    >
    > MySmartPtr<A> obj = new A();
    > obj->Method1();
    > int value = obj->Method2();
    >
    > The operator-> overload allows accessing the A methods as they are
    > accessed via a common pointer.
    >
    > I want to allow the final user call the delete operator as in a common
    > pointer when he wants to explicitly remove the pointer:
    >
    > delete obj;
    >
    >
    > There is a way I could implement an overload of the delete pointer in
    > my MySmartPtr<T> or there is some workaround on this?


    I presume there are other functions omitted from your code above, and
    from your description, it's not clear what semantics you are intending
    to give this smart pointer (though it sounds like you want shared
    ownership). Generally, smart pointers (e.g., std::auto_ptr,
    std::tr1::shared_ptr, boost::scoped_ptr, Loki::SmartPtr, and the smart
    pointer in FAQ 16.22) are responsible for cleaning up after themselves
    at the appropriate time so that the user doesn't have worry about
    deleting anything. Indeed, that's often the primary point. What is your
    point?

    As for overloading delete, you probably don't want to do that because
    it would change the semantics of delete from operating on the object
    (viz. MySmartPtr<>) to operating on the contained object. In other
    words, class-specific new/delete operators are for deleting the smart
    pointer class itself:

    MySmartPtr<T>* pT
    = new MySmartPtr<T>( 0 ); // Calls MySmartPtr<T>::eek:perator new
    delete pT; // Calls MySmartPtr<T>::eek:perator delete

    You could accomplish your goal by supplying a cast to T*, but that
    allows some other dangerous code. The preferred method is to supply a
    reset function:

    template<class T>
    void MySmartPtr<T>::Reset( T* const p = 0 )
    {
    delete mPointer;
    mPointer = p;
    }

    It's best to use RAII and let the smart pointer do the dirty work. See
    the FAQ mentioned above and those following, and see this chapter from
    _Modern C++ Design_ on Loki's smart pointers:

    http://www.informit.com/articles/printerfriendly.asp?p=25264&rl=1

    Cheers! --M
    mlimber, Jan 12, 2007
    #8

  9. > I presume there are other functions omitted from your code above, and
    > from your description, it's not clear what semantics you are intending
    > to give this smart pointer (though it sounds like you want shared
    > ownership). Generally, smart pointers (e.g., std::auto_ptr,
    > std::tr1::shared_ptr, boost::scoped_ptr, Loki::SmartPtr, and the smart
    > pointer in FAQ 16.22) are responsible for cleaning up after themselves
    > at the appropriate time so that the user doesn't have worry about
    > deleting anything. Indeed, that's often the primary point. What is your
    > point?


    Primarily, I want to provide a hierarchy of smart pointers, providing
    the basic implementation in something like AbstractPtr<T>; the basic
    implementation should include null pointer checking on -> and dangling
    pointer avoiding.

    I want to provide also a Ptr<T> : public AbstractPtr<T> implementation
    that should have the same behavior that the standard pointers, but with
    the null pointer checking. This smart pointer should not have any
    semantics (thus, should provide mechanisms to release the pointee
    object manually).
    =?iso-8859-1?q?Ernesto_Basc=F3n?=, Jan 12, 2007
    #9
  10. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Noah Roberts Guest

    Ernesto Bascón wrote:

    > I want to allow the final user call the delete operator as in a common
    > pointer when he wants to explicitly remove the pointer:
    >
    > delete obj;


    No you don't.
    Noah Roberts, Jan 12, 2007
    #10
  11. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    mlimber Guest

    Ernesto Bascón wrote:
    > > I presume there are other functions omitted from your code above, and
    > > from your description, it's not clear what semantics you are intending
    > > to give this smart pointer (though it sounds like you want shared
    > > ownership). Generally, smart pointers (e.g., std::auto_ptr,
    > > std::tr1::shared_ptr, boost::scoped_ptr, Loki::SmartPtr, and the smart
    > > pointer in FAQ 16.22) are responsible for cleaning up after themselves
    > > at the appropriate time so that the user doesn't have worry about
    > > deleting anything. Indeed, that's often the primary point. What is your
    > > point?

    >
    > Primarily, I want to provide a hierarchy of smart pointers, providing
    > the basic implementation in something like AbstractPtr<T>; the basic
    > implementation should include null pointer checking on -> and dangling
    > pointer avoiding.
    >
    > I want to provide also a Ptr<T> : public AbstractPtr<T> implementation
    > that should have the same behavior that the standard pointers, but with
    > the null pointer checking. This smart pointer should not have any
    > semantics (thus, should provide mechanisms to release the pointee
    > object manually).


    Well, IMHO, its generally bad to have an explicit delete anywhere in
    your main code. All resources are best managed by RAII and classes that
    enable it (e.g., std::tr1::shared_ptr).

    As for the hierarchy, I'm not quite sure why you're bothering. If
    you're trying to create a variety of types of smart pointers, check out
    Loki's policy-based solution.

    As for a class that behaves just like a regular pointer but does
    checking, how about something like:

    template<class T>
    class Ptr
    {
    T* p_;
    public:
    Ptr( T* const p=0 ) : p_(p) {}
    operator T*() { assert( p_ ); return p_; }
    T* operator->() { assert( p_ ); return p_; }
    T& operator*() { assert( p_ ); return *p_; }
    };

    class C {};

    Ptr<C> p1( new C );
    delete p1;

    If you had something grander in mind, I think you could achieve the
    same thing (but with considerably more flexibility and code that is
    already written and tested) with Loki's smart pointer by creating a
    storage policy (let's call it NoDelete) identical to
    Loki::DefaultSPStorage, except without the delete in its Destroy()
    member function:

    typedef Loki::SmartPtr<C,
    Loki::NoCopy,
    Loki::AllowConversion,
    Loki::AssertCheck,
    NoDelete> MyPtr;

    MyPtr p2( new C );
    delete p2;

    Hope that helps.

    Cheers! --M
    mlimber, Jan 13, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xamalek
    Replies:
    7
    Views:
    681
  2. MotoK
    Replies:
    59
    Views:
    1,792
    Keith Thompson
    Sep 15, 2006
  3. n2xssvv g02gfr12930

    Smart pointers and member function pointers

    n2xssvv g02gfr12930, Nov 26, 2005, in forum: C++
    Replies:
    3
    Views:
    463
    n2xssvv g02gfr12930
    Nov 27, 2005
  4. Dario Saccavino

    Operator ->* in smart pointers

    Dario Saccavino, Feb 4, 2008, in forum: C++
    Replies:
    3
    Views:
    424
    James Kanze
    Feb 5, 2008
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    657
Loading...

Share This Page