\n\n\n\n
Last time<\/a> we touched upon object lifetime and today we wrap up the basics with a bit of a spicy topic of object ownership. We covered the lifetime quirks, and we found out that manual memory management can be a nightmare, even if we Since we know the rules of The premise was simple:<\/p>\n\n\n\n This was the first attempt at a structured cleanup. As time passed, the initial point began to crumble. More issues arose and the question came up:<\/p>\n\n\n\n Of course, the data is owned by the pointer class. But what if the data is needed elsewhere? In C++98 the only options were reference and raw pointer. If you copied the Simple example:<\/p>\n\n\n\n Another set of problems included inability to express custom deletions for allocated arrays, Now for some express wordings: Object 1 owns another Object 2, if 2\u2019s lifetime does not exceed 1\u2019s and object 1 is responsible for destroying object 2. For fellow mathematicians, it is a weak ordering of lifetime.<\/p>\n\n\n\n The object may be destroyed earlier than its holder, but not the other way around. Although two more pointers came along with Let\u2019s imagine the case, where there are several objects that communicate with one particular one. The easiest example from the real world is the communication with a printer from several devices.<\/p>\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n If we project the same logic to the code, we could expect an object, which represents the printer inside the objects, which represent devices. Pretty simple, isn\u2019t it? Now we impose a restriction: If the printer is out of scope, it shuts down.<\/p>\n\n\n\n Suddenly, the task becomes complex since we can\u2019t say explicitly who owns the printer, and we need to keep it alive, while every device keeps working with it.<\/p>\n\n\n\n The solution would require sharing the ownership between the consumers. How can we solve that? Microsoft pondered about this question and invented COM. Of course, I oversimplify because COM actually solves a lot more than simply sharing, but also hiding the implementation details, uniform representations, ABI control, cross-process communications, etc. But the one thing it does with it is the so-called reference counting. It counts how many objects own the COM interface and does the cleanup when all the consumers are out and refcount is 0.<\/p>\n\n\n\n Here the object itself is responsible for deleting itself and not the consumer, and the same function cleans the underlying memory, which is also responsible for releasing a reference called Well, of course, COM looked like a miracle back in the day. While it was a bit clumsy with implementation, it was doing its job. But what if we are not on Windows? You can still emulate COM and it will in fact work just as well. But implementing it is a nightmare for a regular programmer. C++11 added So far, we have discussed only strong points, but what came with new<\/code> and delete<\/code> in the correct order. There must be something better than that. Well, there is but it comes with its own can of worms.<\/p>\n\n\n\nStructured cleanup<\/h2>\n\n\n\n
new<\/code> and delete<\/code>, namely new<\/code> allocates and delete<\/code> destroys, we never really cared about who is responsible for the object. This caused a lot of confusion in the past. For instance, some API codes from Win32 return strings that should be LocalFree()<\/code>d, like FormatMessage<\/code> or GetEnvironmentStrings<\/code>. POSIX, on the other hand, has strdup<\/code> as a common example of you should free it yourself. <\/em>This model is confusing because you may have a lot of return statements, before which you should always call free<\/code> or delete<\/code>, depending on the operation. However, we have RAII since the very beginning of C++, which adds constructors and destructors. So, in 1998 resourceful people decided to add auto_ptr<\/code><\/a> to the standard.<\/p>\n\n\n\n\n
new<\/code><\/li>\n\n\n\nrelease\/reset<\/code> or a destructor on the end of the block<\/li>\n<\/ul>\n\n\n\nWho owns the data?<\/h2>\n\n\n\n
auto_ptr<\/code> to another place it moved itself to that location, essentially transferring the ownership. That made it impossible to place them into standard containers since the copy of the object did not adhere to copy semantics at all, and the objects were not equal.<\/p>\n\n\n\nauto_ptr<CPClass> a(new CPClass);\nauto_ptr<CPClass> b(a); \/\/copy the a\n\nprintf(\"%p\", a.get()); \/\/ prints 0\nprintf(\"%p\", b.get()); \/\/ prints valid pointer<\/pre>\n\n\n\n
malloc<\/code> allocation, or any specific destructor at all. Quite problematic one might say. C++11 invented move semantics, and along with them new types of pointers; unique_ptr<\/code> was one of them. It disabled copying altogether, which forcd containers like vector to move the contents instead. Furthermore, the argument template also got a custom deleter possibility for custom pointers, array overload and fancy make_unique<>.<\/code> This is a replacement for explicit new<\/code> call, though, it lacks a custom deleter. For that usage you still have to use an explicit constructor. In the same standard auto_ptr<\/code> was deprecated and it was removed completely in C++17.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.kdab.com\/wp-content\/uploads\/stories\/a.drawio.svg\")
<\/a><\/figure>\n\n\n\nauto_ptr<\/code> uniquely owns memory, hence, you can say, that it is a unique pointer. Well, kind of. But the implicit ownership transfer did not allow it to be stable enough. The unique_ptr<\/code> came out and said: \u201cI own the memory! And if you want it, then you will have to take it.\u201d<\/p>\n\n\n\nunique_ptr<\/code>, this is where we should dive a bit deeper.<\/p>\n\n\n\nShared ownership<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.kdab.com\/wp-content\/uploads\/stories\/aaa.drawio-2.svg\")
<\/a><\/figure><\/div>\n\n\nComponent Object Model<\/h4>\n\n\n\n
Release<\/code>. Such a model is a bit confusing at first, but bearg in mind that it was invented even before C++98, in 1993 to be exact, everything comes into place. Does your complex object have some very hard destruction process aside from just delete<\/code>? Maybe it is part of a memory pool and the memory should just go back to it? Fear not, interface->Release()<\/code> got it for you. (The class should still implement the Release<\/code> function; so, no magic here). The model is quite robust and is still in use by Microsoft to this day. Later iterations of Windows API included RAII wrappers, such as ATL CComPtr<\/code> and CComQIPtr<\/code>, WRL Microsoft::WRL::ComPtr<\/code> and finally WinRT with winrt::com_ptr<\/code>. All for their needs but with one purpose.<\/p>\n\n\n\nExplicit sharing<\/h4>\n\n\n\n
shared_ptr<\/code>, which did the same job of sharing the data using atomic reference counting. It did not put the responsibility of destruction to the object, but called destruction himself. Also coming packed with custom deleter and array overloads (which were mostly missing for COM), it came with a particular function, which felt the same as make_unique<\/code>. make_shared<\/code> provided a way to construct a simple shared_pointer<\/code>, but it is storing the reference counter with the object, when constructor allocates two blocks of memory; one for ref counter and one for the object itself.<\/p>\n\n\n\nCurse of sharing<\/h2>\n\n\n\n
shared_ptr<\/code> was a big problem. COM model enforced strict rules for marshalling and modification of the internal state, as well as concurrent access. Also COM always exported only interfaces, so the state stability was on the developer of the implementation. But shared pointer didn\u2019t do anything in that regard, leaving room for a lot of bugs and exploits, that came along.<\/p>\n\n\n\n