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
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
next sibling parent reply 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
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 reply "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
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