在替换共享指针的内容时优化对allocator的调用

Question

Consider this program:

#include <memory>

struct T {
    T() {}
};

void do_something(std::shared_ptr<T> ptr) {
    // Do something with ptr; might or might not leave
    // other copies of ptr in other variables of the
    // program
}

int main() {
    std::shared_ptr<T> ptr = std::make_shared();
    do_something(ptr);
    // ptr might or might not be the only owner
    ptr = std::make_shared();
    return 0;
}

When make_shared executes for the second time, ptr might or might have other sharing owners, depending on what happens at runtime in do_something . If there are no others, ptr destructs and deallocates its previously owned object, when more or less at the same time a new object of the same time is allocated and constructed. Is there any way to avoid the allocation and deallocation, and use the same region for constructing the new object? (the target here is to optimize the two calls to the allocator)

Of course I accept that the new T object will be constructed after the old one will be destructed, while in the code above the opposite happens. So I would like something like ptr.replace<U>(args) which does the following: it decrements ptr 's reference count; if the count goes to zero, there are no other weak references and U is the most derived type of the content of ptr , it destructs the owned object and it constructs a new one with arguments args in the same memory region, avoiding calls to the memory allocator. Otherwise it behaves like ptr = std::make_shared<U>(args) .

Is there anyway to perform this optimization with the current standard library?

Answer 1

There is no mechanism to count the number of weak_ptr s to a shared object. You can only query the strong count (via shared_ptr::use_count ). Note that in multithreaded environments, this is allowed to be an approximate count (ie using a memory_order_relaxed load).

Are you sure this is a performance bottleneck?

Answer 2

Consider allocate_shared . It creates a shared_ptr with an allocator. It is possible to cache the control block of a freed shared_ptr in the allocator, and immediately reuse it in the next allocate_shared call, saving a delete and new.

I doubt that it will make much difference. In a multithreaded application, this allocator can be nontrivial to get both fast and correct.