"in" everywhere

Daniel Gibson metalcaedes at gmail.com
Thu Oct 7 10:51:36 PDT 2010


Steven Schveighoffer schrieb:
> On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson 
> <metalcaedes at gmail.com> wrote:
> 
>> Steven Schveighoffer schrieb:
>>> On Thu, 07 Oct 2010 07:54:14 -0400, atommixz <atommixz at gmail.com> wrote:
>>>
>>>> It would be nice if it were possible to use the "in" expression 
>>>> wherever
>>>> possible. Now it is only implemented for associative. arrays. (Weird).
>>>> Examples of how this could be used:
>>>> - Find string in string
>>>> - Search for a character in a string
>>>> - Search for an item in the array, array of characters, array of 
>>>> strings,
>>>> tuples, enum, structure
>>>> - what else?
>>>  This has been suggested before.  The problem is that 'in' is 
>>> generally considered to be a fast operation (< O(n)) so linear search 
>>> is out.
>>>  -Steve
>>
>> Is it?
>> I wouldn't expect it to be < O(n) on a regular array, but it'd still 
>> be convenient to have instead of iterating over the array and 
>> comparing the contents yourself.
> 
> The problem is with generic code.  Generic code that accepts some type 
> that defines the "in" operator.  What can that generic code expect for 
> performance when using "in"?  As a general rule, generic programming 
> must always assume the worst case, and if we have no rules for 'in', the 
> worst case is linear.  Which means generic code may not use 'in' when it 
> would be a fast operation.  Same thing with indexing.  Try sorting a 
> 'random access' range which uses a linear search on opIndex, and see 
> what the performance is.
> 
> In addition, arr.find(x) seems pretty simple to me.
> 
> -Steve

I didn't know about arr.find(). Is that documented somewhere?

I do however agree that arr.find() is sufficient if it's there.

Cheers,
- Daniel


More information about the Digitalmars-d mailing list