Memory address of an object

  • Thread starter Thread starter kplkumar
  • Start date Start date
K

kplkumar

I want to get the memory address of an object. Can someone tell me how
to do that in C#. Also, I tried using the unsafe and the "&" operator
and could not acheive it. Can you tell me a good way of doing it? I am
new to this and have no clue how to get the memory address.
 
I want to get the memory address of an object.
Click to expand...

Why do you need it? In the garbage collected world of .NET it may
change from one moment to the next.


Mattias
 
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.
 
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.
Click to expand...

In .NET, you can pin an object and thus get hold of a pointer to it. I
don't know exactly what kind of objects you can pin, but I know you need
to use unsafe code to do it.

What's wrong with a Guid?
 
Unfortunately, your supervisors don't know much about .NET.

If you really want something that is unique for each object, you really
have no choice but to use a GUID (it's the easiest way to create something
that is guaranteed to be unique, and doesn't require a manager of your own
to synchronize generation of the unique values).

You would have to associate that guid with the object, and expose it
somehow. This would be best done through a method on your object itself.
If you store it outside your objects, then you will be holding references to
them (in order to do a lookup for the id based on the object) and that will
extend the lifetime of them (and force you to resort to some gnarly lifetime
management code).

You could use a hash, but that isn't guaranteed to generate a unique id
for each object instance.

Besides creating a unique id, what are you trying to do? What is the id
for?

Hope this helps.
 
Lasse,

This isn't completely correct. You don't need to use unsafe code to pin
an object reference. You can use the GCHandle structure to do it.

Also, this would be a very, very, very, VERY MONUMENTALLY BAD idea. If
you pin the object for a long period of time (and it would have to be, so
that the id remains unique), you will end up fragmenting the heap and make
the GC do WAY more work than it needs to.
 
[email protected] said:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.
Click to expand...

Niether naturally implementable, nor a good idea. Convince your boss to use
a guid.

The address of an object in the GCed world is mutable and can change with
each successive GC pass. You can pin the address of an object in memory to
keep the GC from moving it, but this is only intended to be used briefly to
sent a pointer to un unmanaged codeblock because doing so will affect the
GCs performance.

As a sidebar question, if a GC pass opens a gap in the heap between the last
movable object and a pinned one with a higher address, does the heap fragment
like in the c/c++ world or is the free memory pointer placed after the pinned
object with the memory between the two temporarily unusable?
 
"Memory addresses" in .NET aren't really static. Object can be moved around
as part of memory management. You can fix objects in memory, but I don't
think this is really a good solution to your problem.

If there's no other way to uniquely identify your objects, why not have a
static int which is simply incremented each time an object is created and
assigned to the object? Not much different than assigning a Guid in terms of
there not being any particular logic associated with the objects themselves.

Pete
 
[email protected] said:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.
Click to expand...

Hmm... You need something like GetHashCode method
http://msdn.microsoft.com/library/d...ml/frlrfsystemobjectclassgethashcodetopic.asp

Though it does not quarantee uniqueness for all types, but you could write
your onw implementation:

"The default implementation of GetHashCode does not guarantee uniqueness or
consistency; therefore, it must not be used as a unique object identifier for
hashing purposes. Derived classes must override GetHashCode with an
implementation that returns a unique hash code. For best results, the hash
code must be based on the value of an instance field or property, instead of
a static field or property."

Other words calculate your own HashCode based on some properties.
 
How much do your supervisors know about .Net? Did they give you a reason not
to use a Guid?

To use a memory address would be problematic and require unsafe coding. A
Guid is 128 bits in size. Now, the trade-off here is the expense of
resources to get (and use) the memory address, combined with the use of
unsafe code, balanced against using 128 bits of memory. Sounds like a
no-brainer to me. Therefore, I am led to strongly suspect that your
supervisors have no brains.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.
 
Nicholas Paldino said:
Unfortunately, your supervisors don't know much about .NET.

If you really want something that is unique for each object, you really
have no choice but to use a GUID (it's the easiest way to create something
that is guaranteed to be unique, and doesn't require a manager of your own
to synchronize generation of the unique values).
Click to expand...

Very slight correction - GUIDs aren't guaranteed to be unique (they
can't be - you could create more than 2^128 of them, even though the
time taken to do so would be pretty huge). There's just a very, very,
very low probability of duplicates.
 
Other words calculate your own HashCode based on some properties.
Click to expand...

And how would that give uniqueness? GUID is the best option here. Even
though that's not *technically* guaranteed to be unique, it's as close
as you're likely to get (and the chance of getting duplicates is
astronomically small).
 
Jon,

Very, very very low doesn't even begin to describe how low the
probability of generating a duplicate is.

You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to go
through the complete range.

I think that for a program with a VERY finite lifetime (in comparison to
these numbers), it will work just fine. =)
 
The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system. But since we need a unique
id across multiple machines(which run different parts of our system),
they wanted us to generate our own key.

Also, they logic they asked me to use is combine Datetime(to
milliseconds)+ticks+the object's memory address.

Youhave to note that this ID is just used once to put this object into
database and then to be be used as a primary key as well for that
record.
 
Nicholas Paldino said:
Very, very very low doesn't even begin to describe how low the
probability of generating a duplicate is.
Click to expand...

It's actually more than the MSDN docs give - they just say "very low".
You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to go
through the complete range.
Click to expand...

Yes - although of course you don't need to go through the complete
range in order to get a duplicate. By the time I'd seen 2^128-1 GUIDs,
I'd be really, really impressed if the 2^128th happened to be the
missing one :)
I think that for a program with a VERY finite lifetime (in comparison to
these numbers), it will work just fine. =)
Click to expand...

Almost certainly, yes.
 
The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system. But since we need a unique
id across multiple machines(which run different parts of our system),
they wanted us to generate our own key.
Click to expand...

GUIDs are astronomically unlikely to be repeated on *any* system, even
though it's possible.
Also, they logic they asked me to use is combine Datetime(to
milliseconds)+ticks+the object's memory address.

Youhave to note that this ID is just used once to put this object into
database and then to be be used as a primary key as well for that
record.
Click to expand...

That's a really bad idea - what happens if the address is reused by
another object within the same tick? Or the same address is used on a
different box? Unlikely as it is, it's certainly feasible - more likely
than a GUID being duplicated.

Frankly though, if it's to go in the database, I'd have an identity
column in the database and find out what it is when it's autogenerated.
 
"The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system"

Haha, gotta love management....use a GUID.
 
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??
 
Hahah, God, you are so screwed and your manager doesn't even know it.

Your manager is a jack-ass, and you need to quit your job. That's not
theory, that's the truth.

As for finding the address of the object in memory, you can't, it's
going to shift and you will find that it changes throughout the lifetime of
your program.

So use the guid. If you want, I'd be more than willing to speak to your
manager on the phone and let him know why a guid is better than a home grown
solution at this point.
 
Back
Top