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

673. unique_ptr update

Section: 20.3.1 [unique.ptr] Status: CD1 Submitter: Howard Hinnant Opened: 2007-05-04 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [unique.ptr].

View all issues with CD1 status.

Discussion:

Since the publication of N1856 there have been a few small but significant advances which should be included into unique_ptr. There exists a example implementation for all of these changes.

[ Kona (2007): We don't like the solution given to the first bullet in light of concepts. The second bullet solves the problem of supporting fancy pointers for one library component only. The full LWG needs to decide whether to solve the problem of supporting fancy pointers piecemeal, or whether a paper addressing the whole library is needed. We think that the third bullet is correct. ]

[ Post Kona: Howard adds example user code related to the first bullet: ]

void legacy_code(void*, std::size_t);

void foo(std::size_t N)
{
    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
    legacy_code(ptr.get(), N);
}   // unique_ptr used for exception safety purposes

I.e. unique_ptr<void> is a useful tool that we don't want to disable with concepts. The only part of unique_ptr<void> we want to disable (with concepts or by other means) are the two member functions:

T& operator*() const;
T* operator->() const;

Proposed resolution:

[ I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review the proposed resolutions below. ]