www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is the memory address of classinfo the same for all instances of a class?

reply Heywood Floyd <soul8o8 gmail.com> writes:
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.)


BR
/heywood
Jul 02 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd <soul8o8 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.

-Steve
Jul 02 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Jul 2010 09:32:39 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd <soul8o8 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
Jul 02 2010
parent reply Heywood Floyd <soul8o8 gmail.com> writes:
On Jul 2, 2010, at 15:34 , Steven Schveighoffer wrote:


 On Fri, 02 Jul 2010 09:32:39 -0400, Steven Schveighoffer =


<schveiguy yahoo.com> wrote:

=20

 On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd <soul8o8 gmail.com> =




wrote:

=20

=20
 Good day!
=20
=20
 Consider
=20
 // - - - -
 class Foo{}
 auto one =3D new Foo();
 auto two =3D new Foo();
 writefln("one: %x  two: %x", &one.classinfo, &two.classinfo);
 // - - - -
=20
 For me this results in two identical memory addresses "every time".
=20
 Can I rely on this?
 Can I design software based on the assumption that these addresses =






are always the same?

=20
 (I'd like to be able to use the memory address as the key in an =






associative array, for quick by-class

 lookups.)


=20
 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.

=20
 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.

=20
 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.

=20
 -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 ; )
Jul 02 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Heywood Floyd <soul8o8 gmail.com> wrote:


 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.)


Have you profiled your code and found that comparing classinfo is a
bottleneck? If it is, have you considered a two-layer system? i.e.
foo[transmutedClassInfo], where transmutedClassInfo is the result of
another lookup, that is based purely on the pointer to the classInfo?


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


I find it unlikely that will ever happen. The classinfo name should be
the same as the FQN of the class.

-- 
Simen
Jul 02 2010
prev sibling parent Gareth Charnock <gareth.charnock gmail.com> writes:
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<schveiguy yahoo.com> 
wrote:


 On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd<soul8o8 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).
Jul 15 2010