commit 23e14949c91864179173ea84d9b46725b57b755b
parent 46da6dae5ab85e736b180242efda996371711a2d
Author: serge-sans-paille <sguelton@mozilla.com>
Date: Mon, 10 Nov 2025 07:12:32 +0000
Bug 1998636 - Improve documentation of StaticAutoPtr r=nika
In particular make it clear that it behaves differently from
std::unique_ptr in termes of destructor.
Differential Revision: https://phabricator.services.mozilla.com/D271690
Diffstat:
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xpcom/base/StaticPtr.h b/xpcom/base/StaticPtr.h
@@ -16,7 +16,8 @@ namespace mozilla {
/**
* StaticAutoPtr and StaticRefPtr are like UniquePtr and RefPtr, except they
- * are suitable for use as global variables.
+ * never call the owned object destructor and they cannot be constructed through
+ * a pointer.
*
* In particular, a global instance of Static{Auto,Ref}Ptr doesn't cause the
* compiler to emit a static initializer.
@@ -25,7 +26,8 @@ namespace mozilla {
* 0, the default constexpr constructors will result in no actual code being
* generated. Since we rely on this, the clang plugin, run as part of our
* "static analysis" builds, makes it a compile-time error to use
- * Static{Auto,Ref}Ptr as anything except a global variable.
+ * Static{Auto,Ref}Ptr as anything except a global variable. Plus it would leak
+ * memory if it wasn't for global variables.
*
* Static{Auto,Ref}Ptr have a limited interface as compared to ns{Auto,Ref}Ptr;
* this is intentional, since their range of acceptable uses is smaller.
