Hi. If you would track everything in a global structure, you would
basically have to have global locks, so threads would constantly block each
other.

You cannot go with thread local either, as a shared pointer has to be
shared between threads sometimes.

So this is not a good solution unfortunately.

On Fri, Dec 2, 2022, 18:59 Francesco Scappatura via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello everyone,
> I would like to collect feedback from you on this proposal.
>
> *Motivation *
> With C++ smart pointers there is a lot of space for unexperienced
> programmer to run into double free and doing things that are semantically
> wrong.
> Some examples:
> -You can create a raw pointer and initialize two different unique_pointer.
> (double free).
> -You can create a raw pointer and initialize two different shared_pointer.
> (double free + wrong count).
> -You can bind a raw pointer to both a unique and a shared_pointer. (double
> free and semantically incorrect).
>
> These bad things of course will not happen if smart_ptr are used
> correctly, but I were wondering if it's possible to totally remove this
> risk managing smart pointer in a different way.
>
> *Draft solution proposal*
> Keep track of the usage of smart pointers in a single unique
> data-structure.
> What if shared_ptr/unique_ptr/weak_ptr class are tracked using a set of
> static variable of type map<address, count/bool> for tracking the status
> of all the smart pointer of the program?
>
>
> *Proof of concept*
> In these situations, code explains better than words, so I have prepared a
> draft repository with the examples I mentioned and how this different
> internal implementation can help the programmer.
> The repository, of course, also contains a very basic implementation of
> smart_ptr using this different approach. There is a lot room for
> improvement but I hope it's ok to show the intent.
>
> *POC REPO (Each different couple of functions with the same name shows a
> misuse of smart ptr and how a map-based implementation can fix it.)*
> *https://github.com/FrancescoScappatura/smartPtrMapImpl/blob/master/double_free_with_smart_ptr.cpp
> <https://github.com/FrancescoScappatura/smartPtrMapImpl/blob/master/double_free_with_smart_ptr.cpp>*
>
> *Data structure POC*
>
> https://github.com/FrancescoScappatura/smartPtrMapImpl/blob/master/generic_ptr.hpp#L64-L66
>
> This is just a POC but I think there is a lot of space for improvement to
> capture further dangerous situation and make the usage of smart pointer
> even more secure.
> Of course there are also drawbacks, keeping the DS in memory for sure and
> probably other thing that I don't see.
> Hope it's clear!
> Looking forward to receive your feedback and if this has been already
> considered understand why this approach has not been used.
> Thanks.
> Francesco
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>