Sounds great. Let me know how I can help. Do we need an exception for statics that we intend to leak at shutdown? Maybe leakPtr(new Foo)?
Adam On Mon, Jun 28, 2010 at 1:39 PM, Darin Adler <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
