Herb Sutter

Thanks for this suggestion. The current implementation is single-threaded; see the readme for notes about adding concurrency support. For now I'm waiting for feedback and bug reports from actual use...

Yes, I intend to add that eventually because it's natural to want a weak version of a strong (shared) pointer type. I'll probably put it off for a while as...

> How about returning a shared_ptr with a customized dtor? @Zhihao: `shared_ptr` is an owning strong pointer, not a non-owning weak pointer, so users would expect it to keep the...

Thanks again for this suggestion. For now I'm waiting for feedback and bug reports from actual use of the library, and deferring enhancements and optimizations until then but keeping them...

Thanks, I'll take a look. Note that it should be exercised for `vector`.

@FatihBAKIR Actually it is beneficial, in the intended use case is `vector`. In that use, the `vector` will get memory for `N` objects and then individually construct them in-place during...

Thanks again for this PR. For now I'm waiting for feedback and bug reports from actual use of the library, and deferring enhancements and optimizations until then but keeping them...

That's a legitimate point. I still think `ptr_to` handles the large majority of cases, and handles the common case better because it's type-safe. But it may well be a good...

Thanks again for this suggestion. For now I'm waiting for feedback and bug reports from actual use of the library, and deferring enhancements and optimizations until then but keeping them...

Editors call: We agree, thanks. Could you please make two changes to your PR: 1) Change the enforcement rule to just add the word "non-const": > Warn if a local...