Ok, Google didn't help. What is the "C++ smart-pointer trap"?
-
-
-
smart-pointers appear like a simple solution to memory corruption problems, so you happily start allocating objects on the heap and reference them through smart pointers, and indeed memory corruption is 'solved', but performance suffers because of pointer chasing cache misses
-
the problem is that the performance problems usually only show up when it's too late (code has grown too complex), and such code is very hard to optimize, because the cache misses are 'smeared evenly over the whole code base'
-
Got it, thanks. (My solution to this is tagging all memory allocations with a fourcc and using custom allocation strategies as needed. They're also handy for debugging :)
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
Do you ever ref-count the handles?
-
No there is no refcounting, items are destroyed explicitly, and if the handle was shared, the first attempt to access the item from one of the shared handles in the wild would be caught as a dangling access.
-
such a 'dangling access' doesn't need to be a fatal error though, for instance sokol_gfx.h skips any rendering operations where such invalid handles are involved, it's up to the system how this is handled (they could even keep a refcount for shared-access items)
-
Interesting. This seems equivalent to a system with weak_ptr that don't nest.
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
Dunno. You can get most of the benefit of that by using smart pointers which are backed by an object pool. Custom deleters (baked into type) to recycle handle back into pool can be enforced by wrapping the type in a "ObjectHandle" typedef.
-
I think once you want all the benefits (e.g. pool can be reallocated, merge holes in pools, etc...) you end up with a C++ 'SmartHandle' class which is basically the same as an index-handle, but has methods to delegate creation, dereference, destruction to central systems.
-
...you would get a bit of C++ syntactic sugar over a simple C-style handle-type, but the handle would no longer be plain-old-data (which could be a show stopper), I find it nice that such a system works in C just as well as in C++ (or even higher-level managed languages)
নতুন কথা-বার্তা -
-
-
Thank you for promoting proper coding style :). BTW handles (when you skip payload) are much smaller - 2b/4b vs 8b. For some scenarios like rendering this can mean few ms of gains per frame. You can also remove collisions by disabling cell when it's generation reaches max.
-
ah yeah alright, a "generation counter per cell" is a good analogy!
-
I think I'll write up a blog too, I do similar based on
@molecularmusing and@niklasfrykholm posts - but I haven't seen a reference to a more explicit/general post in the wild and think having more is good https://blog.molecular-matters.com/2013/07/24/adventures-in-data-oriented-design-part-3c-external-references/ … (The entity struct) http://bitsquid.blogspot.com/2014/08/building-data-oriented-entity-system.html … -
I think first description was by Chris Butcher in his 2004 (!) talk about Halo 2 engine: http://game-tech.com/Talks/Butcher.doc …
-
Handles used to be a pretty much 'standard' way of doing things on the 'little' platforms (GBA etc), since you only had so much mem and your pools were small (e.g. 256 entities total anyway).
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
This reads like an introduction to ECS without even realizing it :D
-
Ah yes of course, probably should have mentioned it :) The big C++ code base I mentioned at the beginning is basically and 'old-school' entity-component architecture without central systems, where each component is a C++ object on the heap and contains 'game logic code'.
-
What you describe is also remarkably similar to how Sonic the hedgehog 3 (and knuckles) handles object creation. Just instead of C, it's all 68000 ASM (back when C was jokingly called ASM++ lol) and instead of arrays it's just a contiguous block of memory. But still same concept!
-
Basically all games I was involved with from C64 up to say PS2 era do this. ( I still do for private fun projects )
-
Recently, I took the concept and applied it to OpenGL itself. Built a run-time ECS-like wrapper for OpenGL itself. Basically lets me treat my renderer like a configurable template when starting new projects. It's a super useful programming pattern. It's battle tested, lol.
-
Is that code open source somewhere? Sounds interesting.
-
It will be eventually. Right now its still a wip.
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
লোড হতে বেশ কিছুক্ষণ সময় নিচ্ছে।
টুইটার তার ক্ষমতার বাইরে চলে গেছে বা কোনো সাময়িক সমস্যার সম্মুখীন হয়েছে আবার চেষ্টা করুন বা আরও তথ্যের জন্য টুইটারের স্থিতি দেখুন।