|
1 | 1 | --- |
2 | 2 | title: C26411 |
3 | | -ms.date: 11/15/2017 |
| 3 | +ms.date: 08/19/2020 |
4 | 4 | ms.topic: "conceptual" |
5 | 5 | f1_keywords: ["C26411"] |
6 | 6 | helpviewer_keywords: ["C26411"] |
7 | 7 | ms.assetid: 5134e51e-8b92-4ee7-94c3-022e318a0e24 |
8 | 8 | --- |
9 | 9 | # C26411 NO_REF_TO_UNIQUE_PTR |
10 | 10 |
|
11 | | -Passing a unique pointer by reference assumes that its resource may be released or transferred inside of a target function. If function uses its parameter only to access the resource, it is safe to pass a raw pointer or a reference. |
| 11 | +When you pass a unique pointer to a function by reference, it implies that its resource may be released or transferred inside the function. If the function uses its parameter only to access the resource, it's safe to pass a raw pointer or a reference. For additional information, see [C++ Core Guidelines rule R.33](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r33-take-a-unique_ptrwidget-parameter-to-express-that-a-function-reseats-thewidget): *Take a unique_ptr\<widget\>& parameter to express that a function reseats the widget*. |
12 | 12 |
|
13 | 13 | ## Remarks |
14 | 14 |
|
15 | | -- The limitations from the warning [C26410](C26410.md) are applicable here as well. |
| 15 | +- The limitations from the warning [C26410](C26410.md) are also applicable here. |
16 | 16 |
|
17 | | -- The heuristic to detect "release" or "reset" access to the unique pointer is rather naive: we only detect calls to assignment operators and functions named "reset" (case-insensitive). Obviously, this detection doesn’t cover all possible cases of smart pointer modifications (for example, std::swap, or any special non-const function in a custom smart pointer). It is expected that this warning will produce many false positives on custom types, as well as in some scenarios dealing with standard unique pointers. The heuristic will be improved as we implement more checks focused on smart pointers. |
| 17 | +- The heuristic to detect `release` or `reset` access to the unique pointer is naive. We only detect calls to assignment operators and to functions named `reset` (case-insensitive). Obviously, this detection doesn't cover all possible cases of smart pointer modifications. (For example, it doesn't detect `std::swap`, or any special non-**`const`** function in a custom smart pointer). We expect this warning may produce many false positives on custom types, and in some scenarios dealing with standard unique pointers. We expect to improve the heuristic as we implement more checks focused on smart pointers. |
18 | 18 |
|
19 | | -- The fact that smart pointers are often templates brings an interesting limitation related to the fact that the compiler is not required to process template code in templates if it's not used. In some minimal code bases that have limited use of smart pointer interfaces, the checker may produce unexpected results due to its inability to properly identify semantics of the template type (because some important functions may never be used). For the standard `unique_pointer`, this limitation is mitigated by recognizing the type’s name. This may be extended in future to cover more well-known smart pointers. |
| 19 | +- The fact that smart pointers are often templates brings an interesting limitation. The compiler isn't required to process template code in templates if it's not used. In code that makes limited use of smart pointer interfaces, the checker may produce unexpected results. The checker can't properly identify semantics of the template type, because some functions may never get used. For the standard `std::unique_ptr`, this limitation is mitigated by recognizing the type's name. This may be extended in future to cover more well-known smart pointers. |
20 | 20 |
|
21 | | -- Lambda expressions with implicit capture-by-reference may lead to surprising warnings about references to unique pointers. Currently all captured reference parameters in lambdas are reported, regardless of whether they are reset or not. The heuristic here will be extended to correlate lambda fields with lambda parameters in a future release. |
| 21 | +- Lambda expressions that do implicit capture-by-reference may lead to surprising warnings about references to unique pointers. Currently, all captured reference parameters in lambdas are reported, regardless of whether they're reset or not. A future release may extend the heuristic to correlate lambda fields and lambda parameters. |
22 | 22 |
|
23 | 23 | ## Example: Unnecessary reference |
24 | 24 |
|
|
0 commit comments