> The standard states you cannot make [two] unique_ptr<> with the same pointer value within the same compilation unit. > We got this error because the “compile

> The standard states you cannot make [two] unique_ptr<> with the same pointer value within the same compilation unit. > We got this error because the “compiler will only allow one unique_ptr per address” mantra is mostly kaka. I'm curious where the "enforced one unique_ptr per address" idea comes from. I don't think I've ever heard of it before, and I don't see any language implying that in the current (?) draft standard [0]. If anything, I think I'd be a bit surprised if such language existed - after all, creating multiple unique_ptrs to the same place is technically harmless as long as you call release() on enough of them so you don't end up multi-deleting the common object. This also seems like one of those things where "cannot" is more "doing this is a bad idea and you may run into UB" than "the program will not compile if you do this" due to guaranteed enforcement being statically infeasible. The other issues including the QML stuff sounds more like unclear ownership semantics across libraries. I feel the advice here is slightly off-target; if you don't know the ownership semantics of the libraries you're using neither using smart pointers nor avoiding smart pointers are going to be a magic bullet to solve your issues maybe unless you take things to the extreme and allocate everything on startup. > Someone thinks it is a good idea to use Smart Pointers then passes the value to library functions written in C and other languages. Usually these things are in their own threads. Like this. The issue isn't the smart pointers, it's that the ownership semantics of the library function(s) weren't properly accounted for. unique_ptr::release() exists for a reason, after all! > When trying to track down a ghost like crash, nuke all of the Smart Pointers in the code. Make them raw pointers and delete them when you know it is safe. I'm somewhat surprised this is the advice given rather than something like sanitizers and/or valgrind, since those could be significantly less invasive than ripping every smart pointer in a program. Then again, the author states they work on medical devices, and I'm not sure whether sanitizers or valgrind are available for those. In addition, the second sentence is pretty much "don't write bugs", which is technically correct but not exactly helpful; why not "look at your smart pointers again and ensure they aren't violating their ownership guarantees"? You would basically be doing the same thing - lifetime analysis - either way. Heck, you can even re-scope your smart pointers so they'll only go out of scope "when you know it is safe". I don't think I've heard "near heap" and "far heap" used in such a way before, either. Not that it's bad; just different. [0]: https://eel.is/c++draft/unique.ptr https://eel.is/c++draft/unique.ptr