0

On the topic of generating unique index IDs for objects, I thought about using the numeric value of their pointers as ID. Since they are always guarenteed to be unique, it would save me the trouble of generating unique numbers without worrying about overlap.

Basically:

typedef uintptr_t T_Index;

T_Index getIndex()
{
    return (T_Index)this;
}

My question is, would this be safe? Or could pointer addresses change in some way? Obviously move operations would invalidate the index, but if move construction and move assignment are disabled, would it be safe?

This question is similar: How bad is to use integer pointers as unique ids? C++11, but the scope of that question is quite vague. Most people there primarily seem concerned with performance and such, and the OP there stated his objects are never destroyed (which in my case is pretty much certain to happen). My question is not about performance, but about whether or not pointer-based unique indices would be safe to use on un-movable objects.

Minor side topic: Obviously pointers wouldn't work across multiple processes or multiple computers. Although I imagine one could still have a single process/computer dealing out indices (you probably should, anyway) and possibly append a process/computer/IP/port ID as needed.

Community
  • 1
  • 1
Aberrant
  • 3,423
  • 1
  • 27
  • 38
  • 4
    Remember when you delete an object and then create a new one, in theory it could have a previously used pointer value. Is that ok? – Neil Kirk Feb 20 '15 at 02:39
  • @NeilKirk I suppose in a case where that would be an issue, you could always create an empty, unmovable, UniqueIndex class with the sole purpose of having a pointer address assigned to it? – Aberrant Feb 20 '15 at 02:41
  • 2
    This is what I do: `uint64 GenerateId() { static uint64 i = 0; return i++; }` Problem solved! Actually as I am severe OCD, I also assert that i hasn't reached the maximum value, but when would that ever happen?? – Neil Kirk Feb 20 '15 at 02:42
  • @NeilKirk Well, I suppose it's unlikely for most processes to run long enough to go through 18446744073709551616 indices, but it's possible. Also, a uint64 is 8 times as big as an empty object. So far I lean to prefer the pointer approach which feels guaranteed to be safe and simple. – Aberrant Feb 20 '15 at 02:52
  • @Aberrant if you are allocating an empty object on the heap to generate a unique index, be aware that free store allocations tend to have memory overhead. And such allocations are not free, as the cost of maintaining the free list is going to be higher than a special purpose 'free integer' list. – Yakk - Adam Nevraumont Feb 20 '15 at 03:24
  • I did some rough math and I think at 3.6 GHz, even getting 2^64 clock cycles would take you over 162 years, let alone 2^64 index allocations. So I guess the concern about uint64 rolling over is indeed negligible, and it's a tradeoff of memory usage versus heap allocation (where memory usage is probably the lesser evil) – Aberrant Feb 20 '15 at 03:34
  • ...Then again, if your object is unmovable on its own, it would need neither a uint64 nor a heap allocated object. So that still leaves an option for the pointer index approach I suppose. Which, I guess, leads back to the question in that first comment, the answer to which is "yes that's fine". In fact, reusing indices safely was why I started thinking of this in the first place. – Aberrant Feb 20 '15 at 03:57

0 Answers0