On 27/06/2024 22:30, Jonathan Wakely wrote: > On Thu, 27 Jun 2024 at 20:25, François Dumont wrote: >> Thanks for the link, based on it I removed some of the nullptr usages >> keeping only assignments. > That's not necessary. A nullable pointer type is equality comparable > with nullptr_t, and nullptr can be implicitly converted to the pointer > type. Do you prefer that I fully rollback this part then ? In this new version I restored some nullptr usages and kept the removals only when avoiding the conversion without impacting code clarity. But that's questionable of course, let me know. > > Your _S_case function is wrong though: you can't construct the fancy > pointer type from a raw pointer. You need to use > pointer_traits<__node_ptr>::pointer_to(*rawptr). The _S_cast taking a __node_base* is only used when the allocator do not define any fancy pointer. In this new version I've added a comment on it and simply used __node_base* for clarity. > >> François >> >> On 26/06/2024 23:41, Jonathan Wakely wrote: >>> On Wed, 26 Jun 2024 at 21:39, François Dumont wrote: >>>> Hi >>>> >>>> Here is my proposal to add support for fancy allocator pointer. >>>> >>>> The only place where we still have C pointers is at the >>>> iterator::pointer level but it's consistent with std::list >>>> implementation and also logical considering that we do not get >>>> value_type pointers from the allocator. >>>> >>>> I also wondered if it was ok to use nullptr in different places or if I >>>> should rather do __node_ptr{}. But recent modifications are using >>>> nullptr so I think it's fine. >>> I haven't reviewed the patch yet, but this answers the nullptr question: >>> https://en.cppreference.com/w/cpp/named_req/NullablePointer >>> (aka Cpp17NullablePointer in the C++ standard). >>>