How about a Hash template?

Kai Meyer kai at unixlords.com
Mon May 2 07:52:24 PDT 2011


On 04/29/2011 07:13 AM, Jacob Carlborg wrote:
> On 2011-04-28 21:46, Timon Gehr wrote:
>> Andrei Alexandrescu wrote:
>>> On 4/28/11 11:00 AM, Alexander wrote:
>>>> On 28.04.2011 17:46, Andrej Mitrovic wrote:
>>>>
>>>>> It works, but it makes the if statement ugly again. :)
>>>>
>>>> Well, just a bit - still much better than (var == "..." || var =
>>>> "...">||
>> var == "..." ...), don't you think so? ;)
>>>>
>>>> If compiler would support special "in" usage, automatically expanding
>>>> values on the right to series of comparisons (like "var in
>>>> [1,2,3,4,5]"),>>it
>> would be really nice, of course :)
>>>
>>> That was discussed, too. Walter and I support that although it's a
>>> special case. We didn't get around to talk the purist police into
>>> accepting it.
>>>
>>> Andrei
>>
>> Why is this a special case? The 'in' could be extended operator to
>> generally work
>> on arrays (using a simple linear search). The compiler could then
>> optimize the
>> given expression the way suggested (actually even to 1<=var&&var<=5).
>>
>> Why is 'in' not currently defined on arrays? To me it seems like a
>> left-out that
>> should be fixed, because it has quite obvious and useful semantics.
>>
>> Timon
>
> This has been discussed many times before and the general argument
> against it is that "in" is available for associative arrays and it tests
> for keys. With arrays it would test for values.
>

The only thing I can compare this with is python's 'in' operator. It's 
purpose is different though. In python, 'in' returns a boolean, and the 
operator works for any sequence. Associative arrays can return a set of 
keys (hashed), or a list (array) of values, and the 'in' operator can be 
used on either, but defaults to keys.

Not only have I missed a 'set' data structure, but I have missed the 
'in' for arrays as well. It's value is suspect when we consider that 
currently the 'in' operator returns a pointer to the value in the 
associative array. What would we do for an array? You don't need the 
pointer to the value, because you have the value already that you're 
looking for. I see the value in returning the pointer in the associative 
array, so you don't have to do the look-up again.

My argument is that all sequences and containers should support some 
flavor of the "Do I contain this?" question. How many times are we asked 
to build a collection bucket, and then asked to retrieve something put 
in there? In the case of the OP, he has a static compile-time bucket 
that he wants to go poking around in.

If we had a built-in "set" data structure (you know, just the key 
portion of the Associative array), we would solve the OP's problem, and 
make some of my dreams come true.


More information about the Digitalmars-d mailing list