Memory address of an object

  • Thread starter Thread starter kplkumar
  • Start date Start date
Ask your manager if he knows what the type used in SQL Server for
replication IDs is (which would mean the id would have to be unique
across multiple systems).
 
And how would that give uniqueness?
Click to expand...

It would not, unless values of some properties are unique.

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).
Click to expand...

Yes, GUID is the best option.
 
Lenn said:
It would not, unless values of some properties are unique.
Click to expand...

In which case you could just use that single property, or those
combinations of properties. I think it's reasonable to assume that
there is no such combination in this case, given the question.
Yes, GUID is the best option.
Click to expand...

Indeed.
 
Kplkumar,
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...

Why do you make it yourself so difficult to generate those keys?
The way you tell it does me think, just use the unique Id number of your
multiple machines and add to that a datetimetick that starts all on the same
date-time.

The misfailure from this approach is that it can only be used to be unique
in your own organisation and should never be used to mix up or create
uniqueness with data from other organisations and has the change on
programming errors because of the way programmers implement it in the
different programs or just make errors reading the documentation how it
should be done or just forget a part of the code.

Therefore the Guid is so nice, it is completely created for you and
therefore has a low change on errors or other misfailures.

Just my thought

Cor
 
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??
Click to expand...

The following shows how to get the address of the object - and why your
manager shouldn't be allowed to make any decisions about how to find a
unique identifier:

using System;

class Test
{
static void Main()
{
for (int i=0; i < 10; i++)
{
string x = i.ToString();
unsafe
{
fixed (void* y = x)
{
Console.WriteLine (new IntPtr(y));
}
GC.Collect();
}
}
}
}

Use GUIDs - or get the database itself to generate the ID.
 
No, it's not just a "theory". It's widely accepted and used in the idustry.
COM Program IDs in system registry are GUIDs, SQL server uniqueidentifier
data type is GUID. It works for many, but somehow it's not enough for your
managmnet?
 
Nicholas said:
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.
Click to expand...

I did some funny calculations with the numbers of possible GUIDs to
explain the point of the low probability to somebody. I found that for
every square millimeter of earth surface (including the water) there are
665672539443490875 GUIDs available. For the space occupied by a single
human being (estimated to be 100000 square millimeters, you'll have to
stand rather straight to make that true), that'll be
66567253944349087500000 GUIDs. Now, if I was using 10 Million of my GUIDs
every day - an arbitrary number that should suffice to account for all the
new data than's generated for me personally each day - I'll do fine for
18237603820369 years, which is about 6000 times the duration for which the
sun is likely to keep shining. And then I've been forgetting all the
places on the surface of the earth where nobody's currently standing...

I still find these numbers quite astonishing - don't ask me about details
of my calculations, it's been a while :-)


Oliver Sturm
 
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.

Does the jackass know how to read newsgroups? :-o
 
Jon said:
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 :)
Click to expand...

If you use the same .NET program for generating them that would actually
be easy, you could use a generator for the field N_{2^218} to make them.
A *very* simple (and in other ways unusable) implementation would simply
return i on the i'th invocation ;)

Due to the "brithday paradox", if GUID's are generated uniform-randomly
the chance of having seen a collision passes 50% at roughly 2^(128/2) =
2^109 samples. This is still a huge number, atleast a few orders of
magnitude larger than the number of atoms in a human body.
 
Helge Jensen said:
If you use the same .NET program for generating them that would actually
be easy, you could use a generator for the field N_{2^218} to make them.
A *very* simple (and in other ways unusable) implementation would simply
return i on the i'th invocation ;)
Click to expand...

I was assuming a *real* GUID implementation :)
Due to the "brithday paradox", if GUID's are generated uniform-randomly
the chance of having seen a collision passes 50% at roughly 2^(128/2) =
2^109 samples. This is still a huge number, atleast a few orders of
magnitude larger than the number of atoms in a human body.
Click to expand...

Do you mean 2^64? Not sure where the 109 comes from... (I'm not
familiar with the birthday paradox, and slightly too tired to bother
with the maths on the wikipedia entry :)
 
Jon Skeet said:
The following shows how to get the address of the object - and why your
manager shouldn't be allowed to make any decisions about how to find a
unique identifier:

using System;

class Test
{
static void Main()
{
for (int i=0; i < 10; i++)
{
string x = i.ToString();
unsafe
{
fixed (void* y = x)
{
Console.WriteLine (new IntPtr(y));
}
GC.Collect();
}
}
}
}

Use GUIDs - or get the database itself to generate the ID.
Click to expand...


Note that this doesn't give you the object address, it's the address of the
first char in the string object.
Yoy can only use this for array types (and strings, as they are treated as
char[]), however, you can 't use this for other ref types.

Consider this:
object o = new object();
fixed (void* y = o
{

the compiler won't allow to convert other types to void*
or simply put you can't take the address of a reference type (other than
array's)

Willy.
 
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??
Click to expand...

It never ceases to amaze me just how many incompetent managers are out
there.
 
Willy Denoyette said:
Note that this doesn't give you the object address, it's the address of the
first char in the string object.
Yoy can only use this for array types (and strings, as they are treated as
char[]), however, you can 't use this for other ref types.

Consider this:
object o = new object();
fixed (void* y = o
{

the compiler won't allow to convert other types to void*
or simply put you can't take the address of a reference type (other than
array's)
Click to expand...

Ah, true. Oops. I've only ever used unsafe code in one situation in
production code - I'm somewhat rusty on it :(
 
Hmm, I'm pretty sure you'll find few humans standing on water :)
Considering that only 30% of the earth's surface is land, you actually have
3.33 times more GUIDs available than you thought. Of course, that changes
again as soon as you sit down...
--
Kai Brinkmann [MSFT]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
 
I thought that 218 was from your original post.... must have misread
you.... I need to go to bed :(
Why 218/2 though? A GUID is a 128-bit data type.
Click to expand...

So, the "back-of-envelope" calculation, without typos is: 2^(128/2) =
2^64 < 10^20, which is still pretty large -- according to
http://en.wikipedia.org/wiki/Orders_of_magnitude_(numbers)#1018,
it's roughly the number of insects on earth, so they could get one each.
Ah, right. Yes, even I can follow that bit :)
Click to expand...

I can see there is even a specific page on the birthday-attack:
http://en.wikipedia.org/wiki/Birthday_attack, doesn't say much though
and it doesn't explain the maths.

For a more specific solution, using n(n-1)~=n^2, a quick calculation
rewrites p(n;d)~= 1-e^(-n(n-1)/2d) = 0.5 to: n = sqrt(-ln 0,5 * 2d) ~=
2.17e+19 or 2^64.24. Which gives the 50% chance of collision after
slightly more than 2^64 samples.
 
I would theorize that he doesn't know how to read considering what we've
heard to this point. I would also agree with your theory that he's a
jackarse.

The question has been correctly answered.

Nothing to see here people... Move along...
 
Back
Top