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.
Thanks,
Richard
