www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA: How to lose a class

reply David <d dav1d.de> writes:
http://dpaste.dzfl.pl/9172bed3

If mutable keys are allowed in AAs, then why don't they work and why
isn't that documentated? The docs imply this should work, but it
obviously doesn't.

Code:


import std.stdio;

 trusted nothrow void printHash(hash_t h) {
	try { writefln("Called hashing func: %s", h); } catch(Exception e) {}
}

class Key{
	hash_t hash;
	
	this(size_t hash) {
		this.hash = hash;
	}
	
	override hash_t toHash() const {
		printHash(this.hash);
		return hash;
	}
	
	override bool opEquals(Object o) const {
		Key k = cast(Key)o;
		if(k is null) {
			return false;
		}
		
		return hash == k.hash;
	}
	
	override int opCmp(Object o) const {
		Key k = cast(Key)o;
		if(k is null) {
			return -1;
		}
		
		if(k.hash < hash) {
			return -1;
		} else if(k.hash == hash) {
			return 0;
		} else {
			return 1;
		}
	}
}

void main() {
	int[Key] aa;
	
	Key k1 = new Key(10);

	aa[k1] = 3;
	writeln(aa[new Key(10)]);	
	
	k1.hash = 5;
	writeln((new Key(5)) in aa);
	writeln((new Key(10)) in aa);	
	writeln(k1 in aa);
	
}
May 23 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
 ...

Problem has been mentioned here : http://wiki.dlang.org/AA_Implementation_Issues
May 23 2013
parent David <d dav1d.de> writes:
Am 23.05.2013 11:35, schrieb Dicebot:
 On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
 ...

Problem has been mentioned here : http://wiki.dlang.org/AA_Implementation_Issues

Thanks for the link, but this should be mentioned in the docs, not in (some) wiki: http://dlang.org/hash-map.html I also think, the compiler shouldn't even allow mutable instances of classes or structs or arrays, basically anything mutable.
May 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 23, 2013 at 11:35:36AM +0200, Dicebot wrote:
 On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
...

Problem has been mentioned here : http://wiki.dlang.org/AA_Implementation_Issues

I looked over this page again today, and I'm wondering if perhaps instead of balking at the sheer immensity of the task of overhauling AA's, we could begin to chip away at some things that will eventually ease the task. The biggest problem currently is the compiler magic sprinkled throughout the DMD code that generates AA-related code. Perhaps, instead of waiting until the new AA code is ready, we can begin by going over all AA-related code in DMD, and cleaning them up so that they interface with aaA.d only via the AssociativeArray(K,V) template. The idea is to make the DMD code cleaner while still using the current AA implementation, but to move away from hardcoded dependencies on aaA.d so that eventually we can just make the new AA implementation a drop-in replacement. Doing this now instead of waiting for the new implementation to be ready allows us to ensure no bugs are introduced by the decoupling of DMD from aaA.d. Since we're reviewing all DMD code right now anyway, to make it compatible with the C++ to D convertor, this might be a good time to look at all the places that depend on aaA.d and clean them up. T -- They pretend to pay us, and we pretend to work. -- Russian saying
May 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 23 May 2013 at 09:39:48 UTC, David wrote:
 Thanks for the link, but this should be mentioned in the docs, 
 not in
 (some) wiki: http://dlang.org/hash-map.html

 I also think, the compiler shouldn't even allow mutable 
 instances of
 classes or structs or arrays, basically anything mutable.

Are you dav1d from IRC and is your question context related to Volt AA implementation? :) Answer may differ depending on it :)
May 23 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 23 May 2013 at 13:40:44 UTC, H. S. Teoh wrote:
 On Thu, May 23, 2013 at 11:35:36AM +0200, Dicebot wrote:
 On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
...

Problem has been mentioned here : http://wiki.dlang.org/AA_Implementation_Issues

I looked over this page again today, and I'm wondering if perhaps instead of balking at the sheer immensity of the task of overhauling AA's, we could begin to chip away at some things that will eventually ease the task. The biggest problem currently is the compiler magic sprinkled throughout the DMD code that generates AA-related code. Perhaps, instead of waiting until the new AA code is ready, we can begin by going over all AA-related code in DMD, and cleaning them up so that they interface with aaA.d only via the AssociativeArray(K,V) template. The idea is to make the DMD code cleaner while still using the current AA implementation, but to move away from hardcoded dependencies on aaA.d so that eventually we can just make the new AA implementation a drop-in replacement. Doing this now instead of waiting for the new implementation to be ready allows us to ensure no bugs are introduced by the decoupling of DMD from aaA.d. Since we're reviewing all DMD code right now anyway, to make it compatible with the C++ to D convertor, this might be a good time to look at all the places that depend on aaA.d and clean them up. T

Incremental sounds like the right approach. The problems you experienced in your earlier attempt sounded too daunting to do it in one fell swoop.
May 24 2013