Document premature allocator destruction requirement for memory resources

[kammce]

strong_ptr/modules/strong_ptr.cppm

Line 166 in 295aa39

std::pmr::memory_resource* allocator = nullptr;

Why?

The lifetime of the memory resource is not bound to the ref_info that made it, meaning that the memory resource can be destroyed early and cause lifetime issues. A solution around this is to force the memory resources to be managed by strong_ptr.

But how do you get a strong_ptr from an object that needs a strong_ptr for its control block. And the answer is static memory or global allocators. The static strong_ptr's do not need control blocks since they live for the duration of the program and thus can be the backbone of every other strong_ptr. This will ensure memory safety for our smart pointers.

[kammce]

I understood that this would result in a circular dependency and even considered making a new ref counted type just for this. But there is a simpler model to follow. Simply, that we can put a requirement that any memory resources that are used with strong_ptr must have a destructor that terminates if the destructor determines that unfreed memory still exists. This way, we can catch when backing memory for something goes away before its strong_ptrs have been freed. Any resource leak must terminate. Any other option would introduce complexity which would require additional RAM and ROM usage.

With that, I'll change the title to reflect the need to document this aspect of the library.

[kammce]

Removing the blocked by marker for #8 because this change just requires a documentation update.