File: ReplaceAutoPtrTransform.rst

package info (click to toggle)
llvm-toolchain-3.4 1%3A3.4.2-13
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 253,236 kB
  • ctags: 276,203
  • sloc: cpp: 1,665,580; ansic: 298,647; asm: 206,157; objc: 84,350; python: 73,119; sh: 23,466; perl: 5,679; makefile: 5,542; ml: 5,250; pascal: 2,467; lisp: 1,420; xml: 679; cs: 236; csh: 117
file content (72 lines) | stat: -rw-r--r-- 2,462 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
.. 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