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? Can one at least nail the return type somehow (bool vs. int)? > > Thanks, > Richard
