Jump to content

  • Log In with Google      Sign In   
  • Create Account


Unique ID for every objects using reinterpret_cast


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 lride   Members   -  Reputation: 633

Like
0Likes
Like

Posted 15 November 2012 - 04:12 PM

I want my objects to have unique ids, but I heard someone saying using reinterpret_cast<ID>(*itself) will ensure that each objects has an unique ID since no two objects will ever have same memory addresses.
Is this a good idea?
An invisible text.

Sponsor:

#2 frob   Moderators   -  Reputation: 19602

Like
2Likes
Like

Posted 15 November 2012 - 04:26 PM

Probably not.

What happens if you save and reload the game? Every object will be in a different address. What happens when you free an object, and allocate another object later? It could potentially re-use the memory address even though the object is different.

Unique IDs per object can be great for many game designs. A simple number assigned to each object is generally sufficient.
Check out my personal indie blog at bryanwagstaff.com.

#3 saejox   Members   -  Reputation: 714

Like
2Likes
Like

Posted 15 November 2012 - 04:27 PM

no.

same memory address will be used after delete/free called on that object.
it is messy.

just use a id generator class. if you want something more advanced i recommend boost::Uuid

#4 C0lumbo   Crossbones+   -  Reputation: 2147

Like
3Likes
Like

Posted 15 November 2012 - 04:27 PM

I think you need to think about what the unique ID is for.

If you ever need networking, then it's useless, because memory pointers will be different on different machines, if you save games, then you can't save/load your guids, because you can't guarantee the addresses will match when you load. You can't even guarantee that your guids won't be recycled (since the same address might be reallocated after an object is deleted.

So, given those problems, I can't see any advantage calling those things a Guid, rather than being explicit about it and calling it a pointer.

Basically, don't do it.

#5 Sean T. McBeth   Crossbones+   -  Reputation: 1377

Like
12Likes
Like

Posted 15 November 2012 - 06:19 PM

In 15 years of software development, I've never *actually* needed anything more than a sequential sequence starting at 1 for such a thing. I have thought I needed it, but in the end it turned out to be more trouble than it was worth.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]


#6 Zipster   Crossbones+   -  Reputation: 578

Like
1Likes
Like

Posted 17 November 2012 - 08:12 PM

Pointers are also different sizes depending on the target platform. I've worked on projects where the various servers and clients were a mixture of 64- and 32-bit applications, so it would have been very difficult to use any sort of platform-dependent ID type for objects that needed to be communicated between them.

#7 alnite   Crossbones+   -  Reputation: 2061

Like
0Likes
Like

Posted 17 November 2012 - 08:29 PM

If you don't want to worry about incrementing, then you can generate a UUID for every instance.

Edited by alnite, 17 November 2012 - 08:29 PM.


#8 ApochPiQ   Moderators   -  Reputation: 14617

Like
4Likes
Like

Posted 18 November 2012 - 05:01 PM

Just use an incrementing counter.

UUIDs are massive overkill for this kind of thing.

#9 bzroom   Members   -  Reputation: 646

Like
0Likes
Like

Posted 18 November 2012 - 07:16 PM

if you need a very shortlived unqiueness, then the memory address will work fine.

Say you're sorting a handful of pointers, you can simply use the address.

One problem is if these are allocated non-continuous, each ptr is heap allocated, then the sort result will not be deterministic.
Your tools may sort your ai nodes in one order and the build process in another, so when you go to debug node 25 in your tool, it's not the same node 25 that the build process created.

A problem with incrementing IDs is that they wrap. For small tests it may appear that everything works fine. But after soaking your game for a couple days you will very likely wrap your IDs, then you need to deal with "well where do i get the next id from?" you'd need to returned freed ids to a list.

So if you need short lived, automatically recycling ids that simply guarantee uniqueness (locally) and are not deterministic, the memory address is perfectly applicable.
In most other cases, with multiple machines, or multiple runs, where the ids much be the same.. the memory address will fail miserably.

#10 ApochPiQ   Moderators   -  Reputation: 14617

Like
0Likes
Like

Posted 18 November 2012 - 08:46 PM

Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?

#11 Krohm   Crossbones+   -  Reputation: 3011

Like
0Likes
Like

Posted 19 November 2012 - 12:38 AM

Personally I strongly suggest to use an incremental index as well.
Except I've often found it useful to create those indices independantly, for each pool of objects so the id is
(pool, objectIndex) where an object can be accessed simply by pool[objectIndex].
This still has the easiness of the incremental pointer and provides some useful insight on the type of the object (if the various pools are type-coherent) or their lifetime (if the pool is temporally coherent).

#12 bzroom   Members   -  Reputation: 646

Like
0Likes
Like

Posted 19 November 2012 - 07:01 AM

Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?


Maybe there are duplicate entries in the container, and you want to correlate them. Programming is a mysterious world, with many mysterious tasks.

#13 Matias Goldberg   Crossbones+   -  Reputation: 3041

Like
0Likes
Like

Posted 19 November 2012 - 09:10 AM

+1 to incremental index.
Not to mention using memory ptrs makes your application undeterministic. Each time you run the program, if your data is sorted by pointers, the order will always be different.

#14 swiftcoder   Senior Moderators   -  Reputation: 9723

Like
0Likes
Like

Posted 19 November 2012 - 09:19 AM

Not to mention using memory ptrs makes your application undeterministic. Each time you run the program, if your data is sorted by pointers, the order will always be different.

Unless, of course, your allocations are guaranteed to be in-order and contiguous placement allocations...

The world of memory-friendly optimisations is a strange and wonderful place ;)

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#15 ApochPiQ   Moderators   -  Reputation: 14617

Like
1Likes
Like

Posted 19 November 2012 - 08:31 PM


Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?


Maybe there are duplicate entries in the container, and you want to correlate them. Programming is a mysterious world, with many mysterious tasks.


I'm hard pressed to think of a situation that can't be solved by better means than comparing pointer addresses. That's just begging for undefined behavior.

#16 SiCrane   Moderators   -  Reputation: 9489

Like
1Likes
Like

Posted 19 November 2012 - 09:09 PM

Why on earth would you ever sort a container of pointers by their address values? What is that even going to accomplish?

Occasionally, sorting a container of pointers by pointer value can be a performance boost, provided that you need to do batch processes on all the elements in the container, the container contains a sufficient number of pointers, the objects pointed to are sufficiently small enough that multiple objects can fit on a cache line (preferably L1), but the data set is large enough that an appreciable number of cache misses occur, the objects are allocated in a way with low fragmentation and inline overhead and the container is not modified (and hence resorted) frequently. Usually a complete reorganization of data storage is more effective in this kind of situation, but it makes for a low programmer effort speed boost if it works.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS