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

Nikolas Klauser via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Sun Jul 3 05:17:43 PDT 2022


philnik added inline comments.


================
Comment at: libcxx/include/__iterator/reverse_iterator.h:337
+template <class _Iter>
+class _AlgRevIter {
+  _Iter __iter_;
----------------
Mordante wrote:
> Mordante wrote:
> > I'm not really happy with this name, it doesn't tell me anything. I also would like some comment what this iterator wrapper is.
> How is this class tested?
Do you have any naming suggestion? Or would you just like to have it spelled out more like `_AlgorihtmReverseIterator`?


================
Comment at: libcxx/include/__iterator/reverse_iterator.h:337
+template <class _Iter>
+class _AlgRevIter {
+  _Iter __iter_;
----------------
philnik wrote:
> Mordante wrote:
> > Mordante wrote:
> > > I'm not really happy with this name, it doesn't tell me anything. I also would like some comment what this iterator wrapper is.
> > How is this class tested?
> Do you have any naming suggestion? Or would you just like to have it spelled out more like `_AlgorihtmReverseIterator`?
It's tested indirectly through `copy_backward`, `inplace_merge` and `stable_sort`. I'm planning to use it in more algorithms. Would you like have some explicit tests?


================
Comment at: libcxx/include/__iterator/reverse_iterator.h:357
+
+  _LIBCPP_HIDE_FROM_ABI constexpr auto base() const { return __iter_; }
+  _LIBCPP_HIDE_FROM_ABI constexpr decltype(auto) operator*() {
----------------
Mordante wrote:
> In general we prefer not to use compiler deduced `auto` on return types.
That makes sense to me with ABI-relevant parts of the code, but what's wrong with it in an implementation-detail class?


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