[Issue 10733] Add a druntime function to find the pointer to a key of a built-in associative array given the pointer to a value

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10733



--- Comment #3 from hsteoh at quickfur.ath.cx 2013-08-23 11:27:52 PDT ---
Well, it's not that it's not good enough, it's just that with your approach,
the resulting code would be un- at safe, because you have to cast Value* to Key*.
It can't be made @trusted either, because you can't guarantee where the user
code got that Value* from (they could have created a Value variable outside of
the AA, and then the resulting Key* would be an invalid pointer).

Also, based on your other AA bug reports / enhancement requests, it would
appear that the current AA implementation may need to be overhauled anyway, and
adding too many dependencies on the internal implementation would only make
that harder.

For true code reuse to support these different kinds of AA, I think a better
approach is to implement a common Set type. A Set basically is a valueless
hash, it just stores Elements. The current Key/Value AA can then be implemented
by creating an Element whose toHash only hashes the key part of the Element.
This also avoids the current code duplication in byKey and byValue, because the
underlying Set would only have a single range returned by Set.byElement, so
byKey and byValue would just be wrappers around byElement that returns either
the key part or the value part. And byPair would be trivially implemented as
well. (In fact, this is close to what is currently implemented in AA's, byKey
and byValue basically iterates over Slots and returns the key part or the value
part.)

Using this Set, you can implement your ordered AA just by using an Element with
both key and value and next/prev pointers, and you'll be able to iterate over
both keys and values.


One way to achieve this in the current AA implementation might be to use a
zero-size Value, say ubyte[0]. (I'm not sure if this works, but if not, it's
probably a bug that needs to be fixed. In any case, you could work around it by
using a dummy ubyte value that is never used.) Then define a Key struct that
contains both the real key and real value and next/prev pointers to other Keys,
with a toHash that only hashes the "real key" part of the struct. The OrderedAA
wrapper would then translate this Key struct into the user-facing "real" key
and value.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------