Hey all, mfbt recently picked up mozilla::UniquePtr<T or T[]>, a smart pointer for objects created using |new| or |new[]|. UniquePtr will automatically |delete| or |delete[]| its pointer when it's destroyed. (You can also define custom deletion policies if you want.)
Additionally, you can safely embed UniquePtr in properly-written container classes. This is dangerous or impossible with the current alternatives, because they consider the act of copying to *move* the pointer out of the source object (mutating it), into the sink object. mfbt also gained MakeUnique, which works like UniquePtr(new T(...)) or UniquePtr(new T[n]()). With MakeUnique there's no point at which it's possible for the new object to be forgotten, leaked, double-deleted, etc. without mistakes elsewhere. I recommend considering MakeUnique calls as idiomatic, such that the pointer type is obvious and isn't repeated twice. If you do this, |auto| nicely simplifies such declarations: auto memoryPage = MakeUnique<uint8_t[]>(4096); // 4096-byte array auto i = MakeUnique<int8_t>(17); // new int(17) More details and examples of how to use UniquePtr and MakeUnique are here: http://whereswalden.com/2014/07/31/mfbt-now-has-uniqueptr-and-makeunique-for-managing-singly-owned-resources/ As always, the mfbt header itself includes copious documentation and examples of how to use it: http://mxr.mozilla.org/mozilla-central/source/mfbt/UniquePtr.h One last note. UniquePtr is patterned on std::unique_ptr, the C++11 standard version of this idiom. The current mozilla::Scoped class is another recent attempt to address largely the same needs. The older nsAutoPtr and nsAutoArrayPtr classes are even older attempts at a solution, that suffer from the (T&) non-copy-constructor problem mentioned before. Scoped, nsAutoPtr, and nsAutoArrayPtr shouldn't be used now that UniquePtr is available, and the former class is now deprecated (and is slowly being removed). (I consider nsAutoPtr and nsAutoArrayPtr deprecated as well, but it's not within my power to authoritatively declare it so. Nonetheless, you should treat them as such.) Jeff _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
