I am aware, but that restriction shouldn't affect its use for an atomic ref-counted pointer since you can place the count and the pointer next to each other.
How would it work exactly? The layout of a generic shared ptr (but not specifically std::shared_ptr) is:
ptr -> (count, payload)
instead of:
(count, ptr) -> payload
As you can see, count is not alongside the pointer itself as distinct instances of ptrs need to share the count.
Let's say you want to acquire an additional reference to ptr. You need to both copy the current value of ptr and increment count atomically to protect against concurrent modifications of ptr that might drop the last reference to payload.
Delaying the deallocation of payload via hazard pointers, RCU or some other deferred reclamation scheme works, but it is significantly more complex. I believe this is what the rust arc-swap package does internally.
