This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.

### 973. auto_ptr characteristics

Section: 99 [auto.ptr] Status: NAD Editorial Submitter: Maarten Hilferink Opened: 2009-01-21 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [auto.ptr].

View all issues with NAD Editorial status.

Discussion:

I think that the Note of 99 [auto.ptr], paragraph 3 needs a rewrite since "Assignable" is no longer defined as a concept. The relationship of `auto_ptr` with the new `CopyAssignable`, `MoveAssignable`, and `MoveConstructible` concepts should be clarified. Furthermore, since the use of `auto_ptr` is depreciated anyway, we can also omit a description of its intended use.

[ Batavia (2009-05): ]

> We agree with the intent of the proposed resolution. Move to NAD Editorial.

Proposed resolution:

Change 99 [auto.ptr], paragraph 3:

> The `auto_ptr` provides a semantics of strict ownership. An `auto_ptr` owns the ob ject it holds a pointer to. Copying an `auto_ptr` copies the pointer and transfers ownership to the destination. If more than one `auto_ptr` owns the same ob ject at the same time the behavior of the program is undefined. [Note: The uses of `auto_ptr` include providing temporary exception-safety for dynamically allocated memory, passing ownership of dynamically allocated memory to a function, and returning dynamically allocated memory from a function. `auto_ptr` does not meet the `CopyConstructible` and `Assignable` requirements for standard library container elements and thus instantiating a standard library container with an `auto_ptr` results in undefined behavior.

> Instances of `auto_ptr` shall meet the `MoveConstructible` and `MoveAssignable` requirements, but do not meet the `CopyConstructible` and `CopyAssignable` requirements. -- end note]