Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>According to Scott Meyers in Effective C++ (3rd Edition), shared_ptrs are safe across dll boundaries. The shared_ptr object keeps a pointer to the destructor from the dll that created it.</p> <blockquote> <p>In his book in Item 18 he states, "An especially nice feature of tr1::shared_ptr is that it automatically uses its per-pointer deleter to eliminate another potential client error, the "cross-DLL problem." This problem crops up when an object is created using new in one dynamically linked library (DLL) but is deleted in a different DLL. On many platforms, such cross-DLL new/delete pairs lead to runtime errors. tr1::shared_ptr avoid the problem, because its default deleter uses delete from the same DLL where the tr1::shared_ptr is created."</p> </blockquote> <p>Tim Lesher has an interesting gotcha to watch for, though, that he mentions <a href="https://stackoverflow.com/questions/345003/is-it-safe-to-use-stl-tr1-shared-ptrs-between-modules-exes-and-dlls">here</a>. You need to make sure that the DLL that created the shared_ptr isn't unloaded before the shared_ptr finally goes out of scope. I would say that in most cases this isn't something you have to watch for, but if you're creating dlls that will be loosely coupled then I would recommend against using a shared_ptr.</p> <p>Another potential downside is making sure both sides are created with compatible versions of the boost library. Boost's shared_ptr has been stable for a long while. At least since <a href="http://www.boost.org/doc/libs/1_34_0/libs/smart_ptr/shared_ptr.htm" rel="nofollow noreferrer">1.34</a> it's been tr1 compatible.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload