string and char[]

Steven Schveighoffer schveiguy at yahoo.com
Fri Apr 8 13:28:05 PDT 2011


On Fri, 08 Apr 2011 16:12:27 -0400, spir <denis.spir at gmail.com> wrote:

> On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
>>
>> In reality, most times you are not using something as a key and  
>> somewhere else
>> simultaneously. So while theoretically dangerous, it's easy to write  
>> code that
>> isn't dangerous.
>
> What about ref'ed objects used as keys be compared (at least as keys) by  
> ref -- and only by ref.
> This is how Lua tables work (and the reason why they're so fast):
>
> a = {1,1} ; b = {2,2}
> t = {[a]=1 , [b]=2}
> print (t[a], t[{1,1}])  --> 1 nil
>
> a and the second {1,1} key are distinct objects. This is not often what  
> we mean, in the general case. Composite objects actually often are,  
> conceptually, *values*, like a position or color; thus, should be  
> compared by value.
> But they sometimes represent unique "entities", like a game character,  
> which should be compared (as keys and everywhere else) by "unicity" --  
> and only that way. Comparing their state simply makes no sense.

I believe objects are compared that way by default.  But you may want to  
compare them based on their values.

For example, a container may want to compare equal to another container if  
it has all of the same elements, regardless of whether they are the same  
exact instance.

In any case, allowing non-immutable keys in the case where it's just the  
references being compared is a good use case.

-Steve


More information about the Digitalmars-d mailing list