• Advertisement
Sign in to follow this  

Unique ID for every objects using reinterpret_cast

This topic is 1977 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement