Three Unlikely Successful Features of D

[Brad Anderson]

On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

[snip]

I would say the main benefit is having it implemented in the library,
> because that allows the implementation have direct access to key/value
> types. I didn't implement any clever new hashing algorithm at all, I
> just mainly followed the implementation in aaA.d. But having direct
> access to key/value types is a *huge* win.
>
> For example, it lets you accept keys/values that are not strictly the
> AA's key/value type, but can be implicitly converted to them. It lets
> you return keys and values without needing the ugly typeinfo and void*
> casts that are necessary in aaA.d.  This in turn lets you mark many AA
> methods as pure, and almost all as @safe or @trusted. It lets you
> cleanly interoperate with types that define opAssign (currently aaA.d
> does a blind binary copy of data from key/value pointers, which leads to
> potential bugs when the data has subobjects.)
>
>
It's probably far too early to think about this with all the other
important issues you're addressing but have you given much thought to
improving the hashing function?  I haven't hit any issues with the speed of
the current hasher but better performance is always welcome. MurmurHash
seems to be all the rage these days with a lot of languages and systems
adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it compiles down to
~52 instructions on x86). It'd be interesting to see benchmarks with it.
I'm not sure where the current hashing function lives to see what it's like.

Regards,
Brad Anderson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120320/ece5ff80/attachment.html>