Richard Biener <[email protected]> writes: > On Tue, Sep 8, 2026 at 9:38 PM Richard Sandiford > <[email protected]> wrote: >> >> Richard Biener <[email protected]> writes: >> > On Sat, Sep 5, 2026 at 7:29 PM feedable <[email protected]> wrote: >> >> >> >> >> >> On 25/08/2026 13:49, Richard Biener wrote: >> >> > On Tue, Aug 25, 2026 at 1:27 AM feedable via Sourceware Forge >> >> > <[email protected]> wrote: >> >> >> From: feedable <[email protected]> >> >> >> >> >> >> gcc/ChangeLog: >> >> >> >> >> >> * vec.h (array_slice::contains): New function. >> >> >> (array_slice::find): New function. >> >> >> --- >> >> >> gcc/vec.h | 31 +++++++++++++++++++++++++++++++ >> >> >> 1 file changed, 31 insertions(+) >> >> >> >> >> >> diff --git a/gcc/vec.h b/gcc/vec.h >> >> >> index a2ff7a9b77694..9d25678029832 100644 >> >> >> --- a/gcc/vec.h >> >> >> +++ b/gcc/vec.h >> >> >> @@ -2422,6 +2422,15 @@ public: >> >> >> const value_type &back () const; >> >> >> const value_type &operator[] (unsigned int i) const; >> >> >> >> >> >> + /* Check if there is an element equal to V exists in the array. */ >> >> >> + template<class U> >> >> >> + bool contains (const U &v); >> >> >> + >> >> >> + /* Check if there is an element in the array that satisfies the >> >> >> predicate >> >> >> + PRED. */ >> >> >> + template<class F> >> >> >> + bool find (const F &pred); >> >> > Both should have a big fat warning that these are O(n) operations >> >> > and use >> >> > is discouraged. So ... you need those? Absolutely? >> >> Yes, these functions are basically just me extracting loops from RA >> >> into >> >> the functions here. Those uses want to be linear in complexity, and >> >> that >> >> is logical and should be expected of an unsorted vector. >> > >> > I see. vec<>::find does not exist though, I'd like to keep symmetry >> > between >> > vec<> and array_slice<>. Also ... >> > >> >> >> + >> >> >> unsigned size () const { return m_size; } >> >> >> size_t size_bytes () const { return m_size * sizeof (T); } >> >> >> bool empty () const { return m_size == 0; } >> >> >> @@ -2486,6 +2495,28 @@ array_slice<T>::operator[] (unsigned int i) >> >> >> const >> >> >> return m_base[i]; >> >> >> } >> >> >> >> >> >> +template<typename T> >> >> >> +template<typename U> >> >> >> +bool >> >> >> +array_slice<T>::contains (const U &v) >> > >> > vec<> gets away with a single template parameter, why >> > do you need T != U? >> >> U would be more efficient for things like wide_ints, since the thing >> we're searching for might be simpler than a full wide_int. >> >> I know we probably don't want to see arrays of wide_ints very often, >> but it does show how the flexibility can be useful. >> >> OTOH, I wonder whether the above would lead to mismatched sign warnings >> for contains (0) and an unsigned T? If so, I suppose both choices have >> downsides. >> >> >> >> +{ >> >> >> + for (const auto &x : *this) >> >> >> + if (v == x) >> >> >> + return true; >> >> >> + return false; >> >> >> +} >> >> >> + >> >> >> +template<typename T> >> >> >> +template<typename F> >> >> >> +bool >> >> >> +array_slice<T>::find (const F &pred) >> > >> > Similarly, IMO we should constrain F by a signature like >> > >> > ::find (bool (*pred) (const T&)) >> > >> > matching vec::bsearch and friends. >> >> That would prevent using it with lambdas though. > > Then we should "fix" vec::bsearch and friends?
Yeah, I think so. > Can one at least nail the return type somehow (bool vs. int)? I won't pretend to speak to the best way :) Richard
