Container templates and constancy of elements

Stewart Gordon smjg_1998 at yahoo.com
Wed Mar 14 14:02:45 PDT 2012


On 14/03/2012 19:24, H. S. Teoh wrote:
<snip>
> Exactly. AA keys must be immutable, no matter what. Of course, to
> interact nicely with existing code, methods like .opIndex or .get should
> also accept mutable keys for lookup purposes, and .idup them when a new
> entry needs to be created.

This would rely on class authors making sure they define .idup.  We would also need a deep 
version of .idup for array-of-array and array-of-class types.

<snip>
>> (d) guarantees that changes to the data that mess up the data
>> structure will never happen, at least if the programmer doesn't bypass
>> the const system.
> [...]
>
> I believe this is the best way to go. Well, at least for AA's this is
> needed. Otherwise there will always be the possibility that AA's will
> malfunction when the key changes behind the container's back.

Thinking about it, if we're going to go this far, maybe we could just make the key type 
fully immutable whatever it is.  This would enable the key variable in a foreach to be ref 
for efficiency (especially useful if it's a struct type) and still prevent changing of the 
key through it.

But this precludes implementing hash slots as arrays, at least if you want to be able to 
delete elements.  I might have to rethink my strategy here as well.  A linked list would 
get around it but increase the memory allocation overhead - not sure if this is worth 
worrying about.

Stewart.


More information about the Digitalmars-d mailing list