Stl: Revisit the limitation of shared_ptr counter to 32 bit

[AlexGuteniev]

32 bit size of shared_ptr counter limits the number of copies that can be created.
It can potentially overflow in 64 mode.

Note: to create 4.3 billion refs need 69 billion bytes of memory.
It would also take a significant amount of time on x86 due to atomic increment cost.
Still should be possible.

[StephanTLavavej]

This is technically a bug, because nothing in the Standard allows this to fail. (This is also one of the first questions I asked when I started reviewing TR1 code in 2007-2008. Now it's slightly more likely for some enormous program to have a zillion shared_ptr objects.)

The resolution isn't obvious. Increasing both the strong and the weak refcounts from 32-bit to 64-bit implies a potentially significant increase in the size of the control block. Perhaps this should actually be an LWG issue.

[AlexGuteniev]

Possibly there should be shared_ptr::max() and recursive_mutex::max(), similar to latch::max() or vector<T>::max_size() that no one would bother to check, but still the implementation is licensed to UB if violated.