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]