1

I have been reading "Game Engine Architecture - Jason Gregory" and he makes the statement:

A handle acts like a smart pointer in many ways, but it is simpler to implement and tends to be less prone to problems. A handle is basically an integer index into a global handle table. The handle table, in turn, contains pointers to the objects to which the handles refer. To create a handle, we simply search the handle table for the address of the object in question and store its index in the handle.

Gregory, Jason; Jeff Lander; Matt Whiting; Lander, Jeff; Whiting, Matt (2011-12-13). Game Engine Architecture (Page D). A. K. Peters. Kindle Edition.

He then gives a skeletal implementation of a handle table (where handles simply are integer indexes into an array of pointers). What I am not really convinced of is why you would use a handle table vs raw pointers unless you are planning to relocate what is being pointed to?

He does say that it allows you to null out an entry in the table and all handles automatically reflect that. However It would seem that you still need to have a predetermined lifetime and ownership of all objects, and if that is the case it should be possible to simply make sure at the point that you delete the object that noone points to it (best case through some design, worst case through callbacks perhaps).

Smart pointers would allow you to have shared ownership, and certainly you might store a reference count in the handle table , but I am not convinced (and the book gives no evidence to suggest ) that doing so would be more run-time efficient than using say boost::intrusive_ptr.

Maybe I am missing something , but to me it seems more like a choice between raw pointers vs smart pointers (depending on the particular case) whether the lifetime is very well defined (by single ownership), or not.

skimon
  • 1,149
  • 2
  • 13
  • 26
  • 2
    1. Offsets might be smaller than pointers, a lot smaller on x64. So more fit in CPU cache. 2. The table gives you a way to enumerate objects. 3. If you reserve sections of the table for specific object types, you'll get sorting more-or-less for free. – Ben Voigt Apr 18 '14 at 20:07
  • I see what you mean about the offsets being smaller, but would you be reading large chunks of them at a time to benefit from CPU cache? Also what did you mean by getting sorting for free, sorting by type of object? – skimon Apr 18 '14 at 20:16
  • 2
    Yes. Sorting by type of object has benefits for branch prediction, and if you can store your graphical sprites sorted, you might be able to avoid some state changes (e.g. draw multiple regions with the same texture). State changes are relatively expensive operations in OpenGL, for example. – Ben Voigt Apr 18 '14 at 20:21
  • I dont understand. The handle table simply stores the pointers, following each one is a cache miss isnt it? So i dont really see how it can help unless you are only using the data in the handle table ( pointer only) without actually chasing the pointers. I do see however the benefit of having the actual data ( sprites etc) in contiguous memory for locality of reference for the cache. Could you elaborate a bit on some particular use case for the handle table. Still trying to understand the benefit. Thanks – skimon Apr 19 '14 at 18:02
  • 1
    Whether the table holds pointers or actual objects depends on whether you need polymorphism. Another advantage of the handle table is that it's much easier to determine whether an object is valid, than from an arbitrary pointer. – Ben Voigt Apr 19 '14 at 19:09

0 Answers0