unique pointer assignment operator

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Should I assign or reset a unique_ptr?

Given the common situation where the lifespan of an owned object is linked to its owner, I can use a unique pointer one of 2 ways . .

It can be assigned:

The reset method can be utilised:

In the interests of best practice, should I prefer one form over the other?

EDIT: Sorry folks. I over simplified this. The heap allocation occurs in an initialise method and not in the ctor. Therefore, I cannot use initialiser lists.

• smart-pointers

3 Answers 3

From the docs of unique_ptr 's operator= :

Transfers ownership of the object pointed to by r to *this as if by calling reset(r.release()) followed by an assignment from std::forward<E>(r.get_deleter()) .

And all you need of that is the reset call, so it's simpler to just call it directly

• 62 I know it's late, but just for future readers. According to Scott Meyers in his book Effective Modern C++, std::make_unique<T> is preferable, because it offers exception safety: owner = std::make_unique<someObject>(). The problem is that std::make_unique<T> is part of C++14 (not C++11), but here you can find here a good implementation that you can copy-paste. –  Francis Moy Commented May 26, 2015 at 14:47
• @FrancisMoy Possible to point out the exception safety case? –  Mayur Commented Dec 2, 2022 at 2:53
• The question of exception safety does not apply here. Exception safety is relevant when passing multiple arguments to a function, which is safer if each one is created with make_unique. –  Ichthyo Commented Oct 12, 2023 at 15:39

The proper way to do this (that you didn't list) is to use the constructor of owned :

Apart from that I'd prefer reset as you don't create a useless intermediate instance in that case (even though there might be no difference on the machine level as the optimizer can do a lot there).

• 3 "I'd prefer reset as you don't create a useless intermediate instance" - that gets it. Thanks –  learnvst Commented Apr 17, 2013 at 13:37

Short Answer : Both solutions are equivalent. Which to choose is a matter of style or what you want to express.

In Detail : The best and most preferable solution is to use a different design: try to avoid any lifecycle state. This can be achieved by initialising the unique_ptr immediately with the newly heap allocated instance:

Why is this preferable? because it either succeeds or fails as a whole. If the allocation fails or if the ctor of someObject blows up, the construction of owner also throws. This implies: you can get an owner instance only in complete, valid state. As an added bonus, there is no intermediary involved.

However — there are cases when you can not create at initialisation. This is especially the case when your use case explicitly calls for lifecycle state: There may be a situation where you need the owned to be empty sometimes, and only place the someObject later into it, triggered by external events.

In such a situation the question arises if we should assign from make_unique or if we should reset() . Both are equivalent in terms of functionality. Both will safely clean-up another someObject instance which happens to sit in the unique_ptr . Both will transfer ownership and move the deleter alongside.

• using reset() implies the meaning that you change or re-set something that is already there. It may be misleading in cases where the unique_ptr was previously empty. Moreover reset() solution has the benefit of being shorter, more explicit (you can see the "new")
• using assignment form make_unique conveys the meaning on a more abstract level: "make an unique someObject instance and place it here". Some people find that clearer and more precise, other people think it hides the actual allocation. Moreover, make_unique creates an temporary, which is moved into the target. The optimiser is allowed to elide that altogether.

Exception Safety

Generally speaking, make_unique can change the exception safety in some situations. For this reason, it is often recommended to make a habit of using make_unique . In practice, this becomes relevant if you create several unique-managed objects.

If the ctor of one fails, the other one is always safely managed.

However, in the situation discussed here, we only create one object. So what happens in case of an exeption?

• If we use reset(new someObject) , the argument is created first. If this blows up, fine, the reset function is not called. BUT if reset() has to clean-up an existing other instance, and the destructor of that one throws, then we've got a problem: the reset() call will be left by exception, and the newly heap allocated argument leaks.
• on the other hand, if we assign from make_unique() , this special situation is handled safely: if the destructor of the old instance throws, stack unwinding will call the destructor of the temporary returned by make_unique() .

BUT this is a mostly theoretical argument. In practice, there is kind of a »social contract« to the end that decent people do not throw on destruction . And this stands for good reason: objects throwing on dtor call can cause endless pain and basically jeopardise the ability to handle any kind of "situation".

• You don't want a raw call to operator new in your ctor-initializer-list. Prefer to move-construct from the result of make_unique . –  Ben Voigt Commented Oct 12, 2023 at 17:10
• There is nothing inherently evil with an allocation by new . The smart-ptr protects against leaks. @ben-voigt : roughly half of the preople just love abstractions, the other half loves to see the real thing. If you see the concept ("allocation") as the real thing or if you see the implementaton ( operator new ) as the real thing is a matter of attitude. You should not paint the one or the other as evil –  Ichthyo Commented Oct 14, 2023 at 10:42

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged c++ c++11 smart-pointers unique-ptr or ask your own question .

• The Overflow Blog
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...
• Staging Ground Reviewer Motivation

Hot Network Questions

• Investigate why packages are held back, and stop release upgrade
• how do I fix apt-file? - not working and added extra repos
• Using NDSolve to solve the PDEs and their reduced ODEs yields inconsistent results
• I'm not quite sure I understand this daily puzzle on Lichess (9/6/24)
• Does a party have to wait 1d4 hours to start a Short Rest if no healing is available and an ally is only stabilized?
• Were the common people in Germany ("good germans") morally co-responsible of the war crimes of their government?
• Is my magic enough to keep a person without skin alive for a month?
• Can the canonical Eudoxus-real representatives be defined easily?
• Why a minus sign is often put into the law of induction for an inductor
• How does the phrase "a longe" meaning "from far away" make sense syntactically? Shouldn't it be "a longo"?
• Visual assessment of scatterplots acceptable?
• What was the typical amount of disk storage for a mainframe installation in the 1980s?
• Does Psalm 127:2 promote laidback attitude towards hard work?
• Approximations for a Fibonacci-Like Sequence
• A seven letter *
• Sum[] function not computing the sum
• how did the Apollo 11 know its precise gyroscopic position?
• What is the translation of this quote by Plato?
• Starting with 2014 "+" signs and 2015 "−" signs, you delete signs until one remains. What’s left?
• Are others allowed to use my copyrighted figures in theses, without asking?
• Can reinforcement learning rewards be a combination of current and new state?
• How is causality in Laplace transform related to Fourier transform?
• Nausea during high altitude cycling climbs
• VMware workstation kills Ubuntu host - rcu_preempt

• C++ Data Types
• C++ Input/Output
• C++ Pointers
• C++ Interview Questions
• C++ Programs
• C++ Cheatsheet
• C++ Projects
• C++ Exception Handling
• C++ Memory Management

Unique_ptr in C++

std::unique_ptr is a smart pointer introduced in C++11. It automatically manages the dynamically allocated resources on the heap. Smart pointers are just wrappers around regular old pointers that help you prevent widespread bugs. Namely, forgetting to delete a pointer and causing a memory leak or accidentally deleting a pointer twice or in the wrong way. They can be used in a similar way to standard pointers. They automate some of the manual processes that cause common bugs.

Prerequisites: Pointer in C++ , Smart Pointers in C++.

• unique_ptr<A>: It specifies the type of the std::unique_ptr. In this case- an object of type A.
• new A : An object of type A is dynamically allocated on the heap using the new operator.
• ptr1 : This is the name of the std::unique_ptr variable.

What happens when unique_ptr is used?

When we write unique_ptr<A> ptr1 (new A), memory is allocated on the heap for an instance of datatype A. ptr1 is initialized and points to newly created A object. Here, ptr1 is the only owner of the newly created object A and it manages this object’s lifetime. This means that when ptr1 is reset or goes out of scope, memory is automatically deallocated and A’s object is destroyed.

When to use unique_ptr?

When ownership of resource is required. When we want single or exclusive ownership of a resource, then we should go for unique pointers. Only one unique pointer can point to one resource. So, one unique pointer cannot be copied to another. Also, it facilitates automatic cleanup when dynamically allocated objects go out of scope and helps preventing memory leaks.

Note: We need to use the <memory> header file for using these smart pointers.

Examples of Unique_ptr

Lets create a structure A and it will have a method named printA to display some text. Then in the main section, let’s create a unique pointer that will point to the structure A. So at this point, we have an instance of structure A and p1 holds the pointer to that.

Now let’s create another pointer p2 and we will try to copy the pointer p1 using the assignment operator(=).

The above code will give compile time error as we cannot assign pointer p2 to p1 in case of unique pointers. We have to use the move semantics for such purpose as shown below.

Managing object of type A using move semantics.

Note once the address in pointer p1 is copied to pointer p2, the pointer p1’s address becomes NULL(0) and the address stored by p2 is now the same as the address stored by p1 showing that the address in p1 has been transferred to the pointer p2 using the move semantics.

Please Login to comment...

Similar reads.

• Geeks Premier League
• Geeks Premier League 2023
• Best Twitch Extensions for 2024: Top Tools for Viewers and Streamers
• Discord Emojis List 2024: Copy and Paste
• Best Adblockers for Twitch TV: Enjoy Ad-Free Streaming in 2024
• PS4 vs. PS5: Which PlayStation Should You Buy in 2024?
• 15 Most Important Aptitude Topics For Placements [2024]

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

• <cassert> (assert.h)
• <cctype> (ctype.h)
• <cerrno> (errno.h)
• C++11 <cfenv> (fenv.h)
• <cfloat> (float.h)
• C++11 <cinttypes> (inttypes.h)
• <ciso646> (iso646.h)
• <climits> (limits.h)
• <clocale> (locale.h)
• <cmath> (math.h)
• <csetjmp> (setjmp.h)
• <csignal> (signal.h)
• <cstdarg> (stdarg.h)
• C++11 <cstdbool> (stdbool.h)
• <cstddef> (stddef.h)
• C++11 <cstdint> (stdint.h)
• <cstdio> (stdio.h)
• <cstdlib> (stdlib.h)
• <cstring> (string.h)
• C++11 <ctgmath> (tgmath.h)
• <ctime> (time.h)
• C++11 <cuchar> (uchar.h)
• <cwchar> (wchar.h)
• <cwctype> (wctype.h)

Containers:

• C++11 <array>
• <deque>
• C++11 <forward_list>
• <list>
• <map>
• <queue>
• <set>
• <stack>
• C++11 <unordered_map>
• C++11 <unordered_set>
• <vector>

Input/Output:

• <fstream>
• <iomanip>
• <ios>
• <iosfwd>
• <iostream>
• <istream>
• <ostream>
• <sstream>
• <streambuf>

Multi-threading:

• C++11 <atomic>
• C++11 <condition_variable>
• C++11 <future>
• C++11 <mutex>
• C++11 <thread>
• <algorithm>
• <bitset>
• C++11 <chrono>
• C++11 <codecvt>
• <complex>
• <exception>
• <functional>
• C++11 <initializer_list>
• <iterator>
• <limits>
• <locale>
• <memory>
• <new>
• <numeric>
• C++11 <random>
• C++11 <ratio>
• C++11 <regex>
• <stdexcept>
• <string>
• C++11 <system_error>
• C++11 <tuple>
• C++11 <type_traits>
• C++11 <typeindex>
• <typeinfo>
• <utility>
• <valarray>
• C++11 allocator_arg_t
• C++11 allocator_traits
• auto_ptr_ref
• C++11 bad_weak_ptr
• C++11 default_delete
• C++11 enable_shared_from_this
• C++11 owner_less
• C++11 pointer_traits
• raw_storage_iterator
• C++11 shared_ptr
• C++11 unique_ptr
• C++11 uses_allocator
• C++11 weak_ptr

enum classes

• C++11 pointer_safety
• C++11 addressof
• C++11 align
• C++11 allocate_shared
• C++11 const_pointer_cast
• C++11 declare_no_pointers
• C++11 declare_reachable
• C++11 dynamic_pointer_cast
• C++11 get_deleter
• C++11 get_pointer_safety
• get_temporary_buffer
• C++11 make_shared
• return_temporary_buffer
• C++11 static_pointer_cast
• C++11 undeclare_no_pointers
• C++11 undeclare_reachable
• uninitialized_copy
• C++11 uninitialized_copy_n
• uninitialized_fill
• uninitialized_fill_n
• C++11 allocator_arg

std:: unique_ptr

• a stored pointer : the pointer to the object it manages. This is set on construction , can be altered by an assignment operation or by calling member reset , and can be individually accessed for reading using members get or release .
• a stored deleter : a callable object that takes an argument of the same type as the stored pointer and is called to delete the managed object. It is set on construction , can be altered by an assignment operation , and can be individually accessed using member get_deleter .

Template parameters

Member types.

Member functions

Non-member function overloads.

22.5 — std::unique_ptr

Because std::unique_ptr is designed with move semantics in mind, copy initialization and copy assignment are disabled. If you want to transfer the contents managed by std::unique_ptr, you must use move semantics. In the program above, we accomplish this via std::move (which converts res1 into an r-value, which triggers a move assignment instead of a copy assignment).

std::make_unique() doesn’t suffer from this problem because the creation of the object T and the creation of the std::unique_ptr happen inside the std::make_unique() function, where there’s no ambiguity about order of execution.

Understanding unique_ptr with Example in C++11

The smart pointers are a really good mechanism to manage dynamically allocated resources. In this article, we will see unique_ptr with example in C++11. But we don’t discuss standard smart pointers from a library. Rather, we implement our own smart pointer equivalent to it. This will give us an idea of inside working of smart pointers.

Prior to C++11, the standard provided std::auto_ptr . Which had some limitations. But from C++11, standard provided many smart pointers classes. Understanding unique_ptr with example in C++ requires an understanding of move semantics which I have discussed here & here .

But before all these nuisances, we will see “Why do we need smart pointer in 1st place?”:

Why do we need smart pointers? #

• In the above code, the early return or throw statement, causing the function to terminate without variable ptr being deleted.
• Consequently, the memory allocated for variable ptr is now leaked (and leaked again every time this function is called and returns early).
• These kinds of issues occur because pointer variables have no inherent mechanism to clean up after themselves.
• Following class cleans-up automatically when sources are no longer in use:

smart_ptr aka std::auto_ptr from C++98 #

• Now, let’s go back to our func() example above, and show how a smart pointer class can solve our challenge:

• Note that even in the case where the user enters zero and the function terminates early, the Resource is still properly deallocated.
• Because of the ptr variable is a local variable. ptr destroys when the function terminates (regardless of how it terminates). And because of the smart_ptr destructor will clean up the Resource , we are assured that the Resource will be properly cleaned up.
• There is still some problem with our code. Like:

• In this case destructor of our Resource object will be called twice which can crash the program.
• What if, instead of having our copy constructor and assignment operator copy the pointer (“copy semantics”), we instead transfer/move ownership of the pointer from the source to the destination object? This is the core idea behind move semantics. Move semantics means the class will transfer ownership of the object rather than making a copy.
• Let’s update our smart_ptr class to show how this can be done:

std::auto_ptr , and why to avoid it #

• What we have seen above as smart_ptr is basically an std::auto_ptr which was introduced in C++98, was C++’s first attempt at a standardized smart pointer.
• However, std::auto_ptr (and our smart_ptr class) has a number of problems that make using it dangerous.
• Because std::auto_ptr implements move semantics through the copy constructor and assignment operator, passing an std::auto_ptr by value to a function will cause your resource to get moved to the function parameter (and be destroyed at the end of the function when the function parameters go out of scope). Then when you go to access your std::auto_ptr argument from the caller (not realizing it was transferred and deleted), you’re suddenly dereferencing a null pointer. Crash!
• std::auto_ptr always deletes its contents using non-array delete. This means std::auto_ptr won’t work correctly with dynamically allocated arrays, because it uses the wrong kind of deallocation. Worse, it won’t prevent you from passing it a dynamic array, which it will then mismanage, leading to memory leaks.
• Because of the above-mentioned shortcomings, std::auto_ptr has been deprecated in C++11, and it should not used. In fact, std::auto_ptr slated for complete removal from the standard library as part of C++17!
• Overriding the copy semantics to implement move semantics leads to weird edge cases and inadvertent bugs. Because of this, in C++11, the concept of “move” formally defined. And “move semantics” added to the language to properly differentiate copying from moving. In C++11, std::auto_ptr has been replaced by a bunch of other types of “move-aware” smart pointers: std::scoped_ptr , std::unique_ptr , std::weak_ptr , and std::shared_ptr .
• We’ll also explore the two most popular of these: std::unique_ptr (which is a direct replacement for std::auto_ptr ) and std::shared_ptr .

std::unique_ptr with example in C++11 #

• std::unique_ptr is the C++11 replacement for std::auto_ptr . It is used to manage use to manage any dynamically allocated object not shared by multiple objects. That is, std::unique_ptr should completely own the object it manages, not share that ownership with other classes.
• We can convert our smart_ptr we designed above into std::unique_ptr . And for that one thing, we can do is delete the copy constructor & assignment operator so that no one can copy smart pointer.
• As we are not allowing a copy of smart pointer we can’t pass our smart pointer to any function by value or return by value. And this is not good design.
• To pass or return by value, we can add move constructor & move assignment operator, so that while passing or returning by value, we would have to transfer ownership through move semantics. This way we can also ensure single ownership throughout the lifetime of the object.

• This is not the exact implementation of std::unique_ptr as there is deleter, implicit cast to bool & other security features included in an actual implementation, but this gives you a bigger picture of how std::unique_ptr is implemented.

References #

• https://www.learncpp.com/cpp-tutorial/15-1-intro-to-smart-pointers-move-semantics/
• https://stackoverflow.com/questions/106508/what-is-a-smart-pointer-and-when-should-i-use-one
• https://docs.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=vs-2017