[webkit-dev] Tightening up smart pointer usage rules

[Maciej Stachowiak]

I like this idea. Addressing some of the side comments:

- Yes, we should get rid of auto_ptr.
- I can imagine a leakPtr function being more self-documenting than adoptPtr(...).releasePtr() when it appears in code, but on the other hand the greater convenience may lead to using it carelessly. On the third hand, it will definitely stand out if it appears in a patch.

Regards,
Maciej

On Jun 28, 2010, at 1:39 PM, Darin Adler wrote:

> Hi folks.
> 
> I’d like to use our smart pointers more consistently to decrease the chances of memory leaks or other similar problems.
> 
> My proposal is that we have a rule that all calls to "new" are immediately followed by putting the object into a smart pointer. The main types of smart pointer that matter for these purposes are:
> 
>    RefPtr
>    OwnPtr
>    OwnArrayPtr
> 
> Today, we put a new reference counted object into a RefPtr by calling adoptRef. The code looks something like this:
> 
>    PassRefPtr<SharedObject> createSharedObject()
>    {
>        return adoptRef(new SharedObject);
>    }
> 
> I propose we do the same thing with single ownership objects. It would look like this:
> 
>    PassOwnPtr<SingleOwnerObject> createSingleOwnerObject()
>    {
>        return adoptPtr(new SingleOwnerObject);
>    }
> 
> Then it would be a programming mistake to call new without immediately calling adoptPtr or adoptRef. As part of this effort I plan to do the following:
> 
>    1) Add a debugging mode where we assert at runtime if we ref, deref, or destroy a RefCounted object before doing adoptRef. Tracked in <https://bugs.webkit.org/show_bug.cgi?id=27672>.
> 
>    2) Add an adoptPtr function that returns a PassOwnPtr, and a releasePtr function that returns a raw pointer to the PassOwnPtr class.
> 
>    3) Add a PassOwnArrayPtr with similar adoptArrayPtr and releaseArrayPtr functions.
> 
>    4) Add a strict mode to PassOwnPtr and OwnPtr which removes OwnPtr::set entirely and removes the ability to construct a PassOwnPtr or OwnPtr from a raw pointer directly, making it a compile time error to forget to use adoptPtr.
> 
>    5) Once everything compiles with the strict mode, make the strict mode the only mode.
> 
>    6) Add validator rules that make invocation of the "new" operator legal only inside adoptRef and adoptPtr function calls.
> 
> Code that used to say this:
> 
>    OwnPtr<OtherObject> m_otherObject;
>    ...
>    m_otherObject.set(new OtherObject);
> 
> Will now say this:
> 
>    OwnPtr<OtherObject> m_otherObject;
>    ...
>    m_otherObject = adoptPtr(new OtherObject);
> 
> And one thing that’s cool about that is it is quite natural for this to become:
> 
>    OwnPtr<OtherObject> m_otherObject;
>    ...
>    m_otherObject = OtherObject::create();
> 
> I thought I’d mention this to everyone on the list before getting doing significantly more work on this. I think it’s going to work well. Any questions or comments?
> 
>    -- Darin
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev