How to get address of object in memory
Thomas Tempelmann
without the use of a plugin? Allowed is any trick that gets is done
with plain RB code and the use of declares and such. Should work on
all platforms (at least on Windows and Linux, I'd say)
So, the function I want is like this:
Function AddressOfObject (obj as Object) as Integer
--
Thomas Tempelmann - exaggerating over a million times a day!
http://www.tempel.org/rb/ -- The primary source of outdated REALbasic
plugins and examples
SirG3
Module AddressGetter
Function GetAddress(c as object) As integer
Declare Function addr Lib "" Alias "AddressGetter.Test%i4%i4" ( o as
object ) as integer
return addr( c )
End Function
Private Function Test(i as integer) As integer
return i
End Function
End Module
Just don't expect it to be supported =).
-- SirG3
Ed Kleban
on the actual address of any object you can simply put it in a variant and
obtain ObjectReferenceInVariant.hash -- which as of at least RB2006 is
indeed guaranteed to generate a unique value so long as the object remains
in memory and is based on the address -- most likely by simply providing the
address (but I haven't tested that).
Thomas Tempelmann
>
> And of course if what you need is simply an identifier that is unique based
> on the actual address of any object you can simply put it in a variant and
> obtain ObjectReferenceInVariant.hash -- which as of at least RB2006 is
> indeed guaranteed to generate a unique value so long as the object remains
> in memory and is based on the address -- most likely by simply providing the
> address (but I haven't tested that).
Wow, now that's a cool trick!
Unfortunately, it does not work. I tried this:
dim v as Variant, i as Integer
v = obj
i = v.Hash
Then "i" contains the object _ID_ but not the memory address. This ID
is what we see if we enable "show object ids" in the debugger prefs.
Well, it was a good idea.
Thomas Tempelmann
> Unfortunately, it does not work. I tried this:
>
> dim v as Variant, i as Integer
> v = obj
> i = v.Hash
>
> Then "i" contains the object _ID_ but not the memory address. This ID
> is what we see if we enable "show object ids" in the debugger prefs.
I found the solution - all you need is to be a little twisted and you'll
realize that the Object ID is just the memory address word-swapped!
So, here's the function to get the address of an Object:
// this is a trick (suggested by Ed Kleban) to take the obj's Hash
value and turn it into a memory address
dim v as Variant, i as Integer
dim mb as MemoryBlock
mb = new MemoryBlock(4)
v = obj
mb.Long(0) = v.Hash
i = mb.Short(0)
mb.Short(0) = mb.Short(2)
mb.Short(2) = i
addr = mb.Long(0)
Woohooo!
Thomas Tempelmann
>
> Certainly, it's really not hard if you know a few implementation details:
>
> Declare Function addr Lib "" Alias "AddressGetter.Test%i4%i4" ( o as
> object ) as integer
Heheee. That's just the kind of stuff I start figuring out with the app I just
wrote :)
Ed Kleban
not work in all prior versions of RB if you're looking for something that is
open-source and version independent. In fact there is a period of 3 years
where I believe object hashes were guaranteed to be unique but in fact were
not. This just got corrected in RB 2006.
Mars Saxman
Ed Kleban wrote:
> Yeah, well, just understand that this is not guaranteed behavior, and may
> not work in all prior versions of RB
It will likely stop working in future versions of RB. The declare hack
is absolutely unsupported and may disappear at any time with no
replacement (and no apology!). It was never supposed to be made known
outside REAL Software, and the only reason it still works is that I
have been too busy to fix it.
Mars Saxman
REAL Software
Ed Kleban
That sounds like a pretty good version of "not guaranteed".
Thomas Tempelmann
>
> The declare hack
> is absolutely unsupported and may disappear at any time with no
> replacement (and no apology!). It was never supposed to be made known
> outside REAL Software, and the only reason it still works is that I
> have been too busy to fix it.
Well, Mars, I hope you still have lots of other more important work to
do, then...
Sorry, nothing personal ;)
Mars Saxman
Thomas Tempelmann wrote:
> Well, Mars, I hope you still have lots of other more important work to
> do, then...
>
> Sorry, nothing personal ;)
Yes, I understand that, and I understand why it's fun to poke around in
the internals and find out how everything works. I'd just hate to see
people put a lot of work into projects based on this technique, then
find themselves stuck when it goes away. Have fun with it, sure; just
don't build your application around it.
I'm also worried that you guys will write libraries based on this
technique, understanding the risk, but will then release them for the
use of other RB users, who might not know what they're getting into.
Mars Saxman
REAL Software
SirG3
with a few useful functions, but build some kind of limitation (my
idea is refusing to compile on any other RB versions than what it's
known to work with). That limitation could be done in the
compatibility sub block of the 'hackish' items, but it's much easier
to be worked around...
-- SirG3
Asher Dunn
#if RBVersion <> 2006.1 // or whatever
cause a syntax error :-)
#endIf
Asher
-------------------------
Asher Dunn
Head Developer, Fireye Software
http://www.fireyesoftware.com/
AIM, Yahoo, MSN: crazedglkid
SirG3
-- SirG3