{"id":111497,"date":"2025-08-25T07:00:00","date_gmt":"2025-08-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111497"},"modified":"2025-08-16T17:45:26","modified_gmt":"2025-08-17T00:45:26","slug":"20250825-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250825-00\/?p=111497","title":{"rendered":"Thoughts on creating a tracking pointer class, part 11: Repairing assignment"},"content":{"rendered":"

Last time, we made sure that tracking pointers to const objects couldn’t be converted into tracking pointers to non-const objects<\/a>, but I noted that fixing this introduced a new problem.<\/p>\n

We fixed the problem by introducing two new constructors that allow construction of either a tracking_ptr<const T><\/code> or tracking_ptr<T><\/code> from tracking_ptr<T><\/code>. If the destination is a tracking_ptr<T><\/code>, then the copy or move construction from tracking_ptr<T><\/code> merely overrides the copy or move construction inherited from the base class, so there is no redeclaration conflict.<\/p>\n

The problem is that in the case of tracking_ptr<T><\/code>, the new constructors are copy and move constructors since they construct from another instance of the same type. And if you declare a move constructor, then the copy and move assignment operators are implicitly declared as deleted.<\/p>\n

So we need to bring them back.<\/p>\n

template<typename T>\r\nstruct tracking_ptr : tracking_ptr_base<std::remove_cv_t<T>>\r\n{\r\nprivate:\r\n    using base = tracking_ptr_base<std::remove_cv_t<T>>;\r\n    using MP = tracking_ptr<std::remove_cv_t<T>>;\r\n\r\npublic:\r\n    T* get() const { return this->tracked; }\r\n\r\n    using base::base;\r\n    tracking_ptr(MP const& other) : base(other) {}\r\n    tracking_ptr(MP&& other) : base(std::move(other)) {}\r\n\r\n    tracking_ptr& operator=(tracking_ptr const&) = default;<\/span>\r\n    tracking_ptr& operator=(tracking_ptr&&) = default;     <\/span>\r\n};\r\n<\/pre>\n
But now we have the reverse problem: If you declare a copy or move assignment, then the copy and move constructors<\/i> are implicitly declared as deleted.<\/p>\n
So we have to bring those back too:<\/p>\n
template<typename T>\r\nstruct tracking_ptr : tracking_ptr_base<std::remove_cv_t<T>>\r\n{\r\nprivate:\r\n    using base = tracking_ptr_base<std::remove_cv_t<T>>;\r\n    using MP = tracking_ptr<std::remove_cv_t<T>>;\r\n\r\npublic:\r\n    T* get() const { return this->tracked; }\r\n\r\n    using base::base;\r\n    tracking_ptr(tracking_ptr const& other) : base(other) {}      <\/span>\r\n    tracking_ptr(tracking_ptr&& other) : base(std::move(other)) {}<\/span>\r\n    tracking_ptr(MP const& other) : base(other) {}\r\n    tracking_ptr(MP&& other) : base(std::move(other)) {}\r\n\r\n    tracking_ptr& operator=(tracking_ptr const&) = default;\r\n    tracking_ptr& operator=(tracking_ptr&&) = default;\r\n};\r\n<\/pre>\n
And now we have the double-definition problem we saw last time: In the case of tracking_ptr<T><\/code> where T<\/code> is non-const, we have two declarations for the same copy constructor (and two for the same move constructor), which is not allowed.<\/p>\n
There’s another problem: In the case of assigning a tracking_ptr<const T><\/code> to a tracking_ptr<T><\/code>, we actually perform it in two steps: First we convert the tracking_ptr<const T><\/code> to a tracking_ptr<T><\/code>, and then we assign the tracking_ptr<T><\/code> to its destination. This creates a temporary tracking_ptr<T><\/code> that gets linked into the chain, and then unlinked. Can we avoid that inefficiency and just assign it directly?<\/p>\n
It turns out the same trick works for both problems.<\/p>\n
template<typename T>\r\nstruct tracking_ptr : tracking_ptr_base<std::remove_cv_t<T>>\r\n{\r\nprivate:\r\n    using base = tracking_ptr_base<std::remove_cv_t<T>>;\r\n    using Source = std::conditional_t<std::is_const_v<T>,<\/span>\r\n        base, tracking_ptr<std::remove_cv_t<T>>>;        <\/span>\r\n\r\npublic:\r\n    T* get() const { return this->tracked; }\r\n\r\n    using base::base;\r\n    tracking_ptr(Source<\/span> const& other) : base(other) {}\r\n    tracking_ptr(Source<\/span>&& other) : base(std::move(other)) {}\r\n\r\n    tracking_ptr& operator=(Source const& other) {   <\/span>\r\n        static_cast<base&>(*this) = other;           <\/span>\r\n        return *this;                                <\/span>\r\n    }                                                <\/span>\r\n    tracking_ptr& operator=(Source&& other) {        <\/span>\r\n        static_cast<base&>(*this) = std::move(other);<\/span>\r\n        return *this;                                <\/span>\r\n    }                                                <\/span>\r\n};\r\n<\/pre>\n
If creating a tracking_ptr<const T><\/code>, then we accept assignment or construction from either tracking_ptr<T><\/code> or tracking_ptr<const T><\/code>. But if creating a tracking_ptr<T><\/code> where T<\/code> is non-const, then we accept assignment or construction only from another tracking_ptr<T><\/code>. This is expressed in the definition of Source<\/code>, which says that tracking pointers to const things can accept the base type, which means that it will accept any type of tracking pointer to that thing (either to a const or non-const thing). But if it’s a tracking pointer to a non-const thing, then it accepts only tracking pointers to the same non-const thing.<\/p>\n
We also have to write out the copy and move assignment operators. We could use = default<\/code> in the case where the Source<\/code> is equal to tracking_ptr<T><\/code>, but if dealing with a tracking pointer to a const thing, the Source<\/code> is the base<\/code>, and the compiler doesn’t know how to default-assign that. So we just write it out explicitly, which works for both cases.<\/p>\n
So are we done? I guess.<\/p>\n
But wait.<\/p>\n
Recall that the complexity of moving a trackable object is linear in the number of tracking pointers because we have to update all the tracking pointers to point to the new location of the moved object. But we can get the cost down to O<\/var>(1) if we are willing to make some concessions. We’ll look at this alternate design next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Restoring things that were automatically deleted.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-111497","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Restoring things that were automatically deleted.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111497","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=111497"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111497\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=111497"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111497"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111497"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}