Details
- Reviewers
• Quuxplusone Mordante ldionne var-const - Group Reviewers
Restricted Project - Commits
- rG1cfa4857693b: [libc++] Implement P1165R1 (Make stateful allocator propagation more consistent)
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It would help to mention the paper's title "Make stateful allocator propagation more consistent", in the PR's topic line.
LGTM modulo test nits. The table in p1165r1 says libc++ needs to change in exactly 5 places, and I see exactly 5 places being changed here, so that seems good to me.
libcxx/include/string | ||
---|---|---|
4216–4218 | Throughout, I'd prefer to see _String (or even _Self) instead of __string, to avoid confusion with std::string and <__string>. But maybe that's controversial, I'm not sure. | |
libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp | ||
27–28 | Nit: Since the first mention on the line is of T, I'd prefer if s/value_type/T/ on the second mention as well. | |
32 | It would be slightly better if you could find a way to distinguish returned_alloc = lhs_alloc.select_on_container_copy_construction(); from (void) lhs_alloc.select_on_container_copy_construction(); returned_alloc = lhs_alloc; i.e., your select_on_container_copy_construction should do something observably different from just making a straight copy. I'm not sure what that would be, though. Maybe here return soccc_allocator(soccc_count + 1)... but that seems too "cute/clever" to me. You might have to add a second data member for that purpose. It might not be worth the bother. | |
146 | In tests, [[maybe_unused]] should be considered a code smell. Don't you need to assert(r.get_allocator().soccc_count == &soccc_rhs) afterward, i.e. the correct allocator got propagated? If you check every postcondition, [[maybe_unused]] should basically never be necessary. |
The get_soccc() getter may be overkill (versus just making those members public). Consider making the getters const-qualified. But LGTM!
We need to update the status page, and also please add a release note!
libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp | ||
---|---|---|
11 | Add: // This test ensures that we properly propagate allocators, per https://wg21.link/p1165r1 | |
45 | Can we template that on CharT and run the test for both char and wchar_t (if !defined(TEST_HAS_NO_WIDE_CHARACTERS))? The reason I'm asking is that we explicitly instantiate some string methods in the dylib for char, but not for wchar_t. We expect the behavior for char and wchar_t to be the same, however I could imagine a case where they don't match (for example in back-deployment cases for char, since operator+ is in the dylib). Adding wchar_t will help shake out these potential differences. Incidentally, I don't understand why this test passes on Apple backdeployment, since I would expect it to use operator+ in the dylib, which doesn't do SOCCC properly. |
libcxx/include/string | ||
---|---|---|
4164–4167 | Is there any reason why we don't implement those naively like in the Standard? I don't think there's any performance gain here, right? This applies to all the overloads AFAICT. |
libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp | ||
---|---|---|
191 | wchar_t |
- Address comment
libcxx/include/string | ||
---|---|---|
4164–4167 | IIUC this implementation makes only one allocation, while making a copy and appending makes two allocations. |
libcxx/include/string | ||
---|---|---|
4164–4167 | Oh, right, because we already reserve enough space for the append to be allocation-free. Makes sense. |
Is there any reason why we don't implement those naively like in the Standard? I don't think there's any performance gain here, right? This applies to all the overloads AFAICT.