On 02/07/10 15:18, Heywood Floyd wrote:

On Jul 2, 2010, at 15:34 , Steven Schveighoffer wrote:

On Fri, 02 Jul 2010 09:32:39 -0400, Steven Schveighoffer<schvei...@yahoo.com>  
wrote:

On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd<soul...@gmail.com>  wrote:


Good day!


Consider

// - - - -
class Foo{}
auto one = new Foo();
auto two = new Foo();
writefln("one: %x  two: %x",&one.classinfo,&two.classinfo);
// - - - -

For me this results in two identical memory addresses "every time".

Can I rely on this?
Can I design software based on the assumption that these addresses are always 
the same?

(I'd like to be able to use the memory address as the key in an associative 
array, for quick by-class
lookups.)

Use classinfo.name.  The classinfo is the same memory address in the same 
executable/dynamic library.  If you open another D dynamic library, the 
classinfo address for the same class may be different, but the name will be the 
same.

Note that comparing classinfo.names will be just as fast as comparing classinfo 
addresses if the names are at the same address (which will be true if the 
classinfo is at the same address) because the string comparison function 
short-circuits if the addresses are the same.

Duh, just realized, classinfos should use this same method to compare.  Just 
use the whole class info as the key, don't take the address.

-Steve


Alright thanks!

Ok, loading in code dynamically changes the addresses. Good point. Thanks!

I looked up the TypeInfo_Class-implementation and it seems to compare class 
names. So that looks good. Will use the classinfos directly like you suggested. 
Seems proper.


***

Hm, but still, I can't quite let go of this.
Even if the string comparer can short-circuit, it still has to go through 
strings that are _not_ of the same address untill it spots a difference, as 
they could potentially be equal anyway?

I noted that the classinfo.name-strings typically looks like this:

        classtype.Foo
        classtype.Bar
        classtype.Cat
        classtype.Dog

Doesn't this first "classtype."-part introduce overhead when these strings are 
used as keys in an AA? The string comparer more or less always have to check the first 10 
chars, which are equal for all. (I know I'm being picky here. But the whole using memory 
addresses-thing came from the fear of string comparisons being suboptimal.)

/heywood

(PS. Feature-request: move the "classtype."-part of classinfo names to the end 
; )

Would simply comparing slices such as classtype.name[10..$] work? Or if you're not sure about classtype always being present every single time (I don't know if it is), perhaps write a compile time function that takes a string and appends a simple string checksum to the front? Then swap classinfo.name for f(classinfo.name).

Reply via email to