Herb Sutter is an author and speaker, a software architect at Microsoft, and chair of the ISO C++ standards committee.
View all posts by Herb Sutter
Published
3 thoughts on “GotW #103: Solution”
I would like to see non-thread safe shared pointer. Why? It is huge overhead inside because of atomic operations. Examples of single-threaded applications: SolidWorks, AutoCad, etc. Why should I pay for thread-safety in non-threaded environment? I’ll be happy with some std::intrusive_ptr…
There is one case I can think of where one might prefer to avoid using make_shared. If you know that there will be many weak_ptrs pointing to your object whose lifetime is longer than the shared object itself.
In the case of using make_shared the memory for the entire memory block will only be released after all the weak_ptrs are destroyed while in the case of regular new the memory block of the object will be released when all strong pointers are gone and only the memory block for the reference counts will stay around waiting for the weak_ptrs to die.
Sutter’s Mill 
I would like to see non-thread safe shared pointer. Why? It is huge overhead inside because of atomic operations. Examples of single-threaded applications: SolidWorks, AutoCad, etc. Why should I pay for thread-safety in non-threaded environment? I’ll be happy with some std::intrusive_ptr…
I expanded a bit on my previous comment in a blog post named maked_shared almost a silver bullet.
There is one case I can think of where one might prefer to avoid using make_shared. If you know that there will be many weak_ptrs pointing to your object whose lifetime is longer than the shared object itself.
In the case of using make_shared the memory for the entire memory block will only be released after all the weak_ptrs are destroyed while in the case of regular new the memory block of the object will be released when all strong pointers are gone and only the memory block for the reference counts will stay around waiting for the weak_ptrs to die.