[PATCH] D35863: Use the allocator's pointers for deallocation in `std::list`

Eric Fiselier via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 2 16:39:39 PDT 2017


EricWF requested changes to this revision.
EricWF added a comment.
This revision now requires changes to proceed.

First, this patch would need tests before continuing, Could you please them? The list tests live under `test/std/containers/sequences/list`.  Let me know if you have any questions or need any help writing tests.

That being said. I'm not sure this patch is viable (or currently correct). First, LWG 2260 <https://cplusplus.github.io/LWG/lwg-defects.html#2260> was resolved at the Toronto meeting by requiring `::pointer_to(r)` to be valid on allocator pointers, so I'm not sure your point about "not returning a deallocatable pointer" is valid anymore. In fact this seems to suggest that implementations should store raw pointers (since fancy-pointers don't require base <--> derived conversions), and then use `pointer_to` to generate the fancy-pointer for deallocation.

I understand the above behavior is quite limiting for fancy-pointers, since as you say, fancy-pointers often depend on information stored in the allocator in order to be constructed. However this point would have to be addressed to the committee in order for anything to be done about it.

Even if your point were valid, I'm not sure it's possible to correctly remove our dependency on `pointer_to` (though you're free to try). Leaving even one call to `pointer_to` within list seems like the manifestation of a bug.

Another problem to addressing this issue is that the pointer types used in `list`, `map`, `unordered_map`, ect are different in ABI v1 and ABI v2,  and correctly converting between them is overly complicated and easy to get wrong.


https://reviews.llvm.org/D35863





More information about the cfe-commits mailing list