llvm-capstone/clang-tools-extra/docs/ReplaceAutoPtrTransform.rst
Chandler Carruth d9063c46f5 Rename cpp11-migrate to clang-modernize.
There is no reason to expect this tool to be limited to C++11, it seems
very likely to be of on-going interest. It seems likely to be useful for
modernizing even as new libraries come out in TSes and other formats
than a complete standard. Fundamentally, we need something a bit more
general. After some discussion on the list, going with
'clang-modernize'.

I've tried to do a reasonably comprehensive job of fixing up the names,
but I may still have missed some. Feel free to poke me if you spot any
fallout here. Things I've tried reasonably hard to find and fix:

- cpp11-migrate -> clang-modernize
- Migrator -> Modernizer
- Clean up the introductory documentation that was C++11 specific.

I'll also point out that this tool continues to delight me. =] Also,
a huge thanks to those who have so carefully, thoroughly documented the
tool. The docs here are simply phenomenal. Every tool should be this
well documented. I hope I have updated the documentation reasonably
well, but I'm not very good at documentation, so review much
appreciated.

llvm-svn: 189960
2013-09-04 17:35:07 +00:00

73 lines
2.4 KiB
ReStructuredText

.. index:: Replace-AutoPtr Transform
=========================
Replace-AutoPtr Transform
=========================
The Replace-AutoPtr Transform replaces the uses of the deprecated class
``std::auto_ptr`` by ``std::unique_ptr`` (introduced in C++11). The transfer of
ownership, done by the copy-constructor and the assignment operator, is changed
to match ``std::unique_ptr`` usage by using explicit calls to ``std::move()``.
The transform is enabled with the :option:`-replace-auto_ptr` option of
:program:`clang-modernize`.
Migration example:
.. code-block:: c++
-void take_ownership_fn(std::auto_ptr<int> int_ptr);
+void take_ownership_fn(std::unique_ptr<int> int_ptr);
void f(int x) {
- std::auto_ptr<int> a(new int(x));
- std::auto_ptr<int> b;
+ std::unique_ptr<int> a(new int(x));
+ std::unique_ptr<int> b;
- b = a;
- take_ownership_fn(b);
+ b = std::move(a);
+ take_ownership_fn(std::move(b));
}
Known Limitations
=================
* If headers modification is not activated or if a header is not allowed to be
changed this transform will produce broken code (compilation error), where the
the headers' code will stay unchanged while the code using them will be
changed.
* Client code that declares a reference to an ``std::auto_ptr`` coming from code
that can't be migrated (such as a header coming from a 3\ :sup:`rd` party
library) will produce a compilation error after migration. This is because the
type of the reference will be changed to ``std::unique_ptr`` but the type
returned by the library won't change, binding a reference to
``std::unique_ptr`` from an ``std::auto_ptr``. This pattern doesn't make much
sense and usually ``std::auto_ptr`` are stored by value (otherwise what is the
point in using them instead of a reference or a pointer?).
.. code-block:: c++
// <3rd-party header...>
std::auto_ptr<int> get_value();
const std::auto_ptr<int> & get_ref();
// <calling code (with migration)...>
-std::auto_ptr<int> a(get_value());
+std::unique_ptr<int> a(get_value()); // ok, unique_ptr constructed from auto_ptr
-const std::auto_ptr<int> & p = get_ptr();
+const std::unique_ptr<int> & p = get_ptr(); // won't compile
* Non-instantiated templates aren't modified.
.. code-block:: c++
template <typename X>
void f() {
std::auto_ptr<X> p;
}
// only 'f<int>()' (or similar) will trigger the replacement