Re: Custom memory manager and calling unref for Cairo::RefPtr<Cairo::Context>

[Murray Cumming <murrayc murrayc com>]

On Tue, 2008-08-05 at 11:45 +0400, Roman Yazmin wrote:
> Sorry it took so long to reply.
>         
>         the pCppRefcount_ member is not allocated in cairo, it is
>         allocated using 'new' (see line 228:
>         http://cgit.freedesktop.org/cairomm/tree/cairomm/refptr.h#228).  Since it's defined in a header, it should be using your custom new operator.  I just did a very crude test and i was able to override new and delete and both the creation and deletion of the pCppRefcount_ member used my custom allocation functions.  Is it possible that your custom allocator has a bug?
>         Jonner
> 
> Thank for reply. Yes you right,  pCppRefcount_ is allocated by my
> custom 'new', but please take a look at line 286
>                 template <class T_CppObject> inline
>                 RefPtr<T_CppObject>&
>                 RefPtr<T_CppObject>::operator=(const
>                 RefPtr<T_CppObject>& src)
>                 {
>                   RefPtr<T_CppObject> temp (src);
>                   this->swap(temp);
>                   return *this;
>                 }
>          
>         As I understand  pCppRefcount_ and pCppObject_ will be swaped
>         with  values returned from create_cairo_context function.
> It is really strange why pCppObject_ can be deleted, but pCppRefcount_
> not.

The underlying C++ instance will have been created inside cairomm, with
a normal new, so it really should be deleted using a normal delete.

I am not surprised that you can break a template's behaviour by
redefining new and delete for that template. 

>                 Is it possible that your custom allocator has a bug?
>         
>         This is well known nedmalloc allocator.

> 
-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com