[libcxx-commits] [PATCH] D128864: [libc++] Fix algorithms which use reverse_iterator

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Jul 21 09:16:11 PDT 2022


ldionne added a comment.

I am also not happy with this, but I don't see a better solution for fixing the underlying issue.

Other alternatives:

1. Stop using `reverse_iterator` in the implementation of algorithms. That would mean reimplementing some of the logic we have in `std::copy` for lowering to `memmove`, unwrapping iterators and more. I'm ambivalent about this, but @philnik seems to be convinced that it would be worse than this patch, and I would tend to agree.
2. Stop using `reverse_iterator` in the implementation of algorithms, and don't try to apply optimizations in those. That way we lose the complexity of this patch, but we also lose the perf benefits. I don't think we should do this.

@philnik, can you please file a CWG issue when the LLVM 15 branch is done? On a related note, I should create a space where we can share issue drafts for libc++ contributors to look at and chime in on. I'm taking this as an action item.

@var-const Can you think of other alternatives that would fix those algorithms with C++20 hostiles iterators?



================
Comment at: libcxx/include/__iterator/reverse_iterator.h:338
 template <class _Iter>
-using _ReverseWrapper = reverse_iterator<reverse_iterator<_Iter> >;
+using _AlgRevIter = reverse_iterator<_Iter>;
+#else
----------------
What do you think about `__unconstrained_reverse_iterator` instead? It's a mouthful, but we don't plan on using it in too many places anyways.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128864/new/

https://reviews.llvm.org/D128864



More information about the libcxx-commits mailing list