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.
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.
Instances of auto_ptr shall meet the MoveConstructible and MoveAssignable requirements, but do not meet the CopyConstructible and CopyAssignable requirements. -- end note]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.