[PATCH] D58088: [adt] Add raw_pointer_iterator to iterate over std::unique_ptr<> collections

Daniel Sanders via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 21 13:26:01 PST 2019


dsanders added a comment.

In D58088#1404872 <https://reviews.llvm.org/D58088#1404872>, @dblaikie wrote:

> In D58088#1404769 <https://reviews.llvm.org/D58088#1404769>, @dsanders wrote:
>
> > I just noticed a big simplification that doesn't need C++20 features or new classes. This:
> >
> >   template <typename WrappedIteratorT,
> >             typename T1 = typename std::remove_reference<decltype(**std::declval<WrappedIteratorT>())>::type,
> >             typename T2 = typename std::add_pointer<T1>::type>
> >   using raw_pointer_iterator = pointer_iterator<pointee_iterator<WrappedIteratorT, T1>, T2>;
> >
> >
> > is functionally equivalent to the raw_pointer_iterator in this patch. pointee_iterator derefs the unique_ptr, while pointer_iterator produces the raw_pointer. If that version sounds good to you then I think it makes sense to revert the llvm::to_address() patch, switch to this implementation and fold this into the GISel Combiner patch as at that point it's too trivial to warrant a dedicated patch. Does that sound good?
>
>
> Beyond probably some annoying compile-time complexity/overhead (& maybe similar debugging confusion with the extra layers of abstraction) - I'm guessing this wouldn't support null pointers (because pointee_iterator probably dereferences unconditionally?) which would be a bit problematic, I'd reckon?


It's not a problem for my intended uses at least. I can just make it specific to the GISel Combiner rather than put it in a common header.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58088





More information about the llvm-commits mailing list