3 ms·
I’m not a game programmer but with RAII for example (I realize this is not a C idiom), it really becomes a non-issue if you have things scoped properly. For eve
by flatline 7y ago
I’m not a game programmer but with RAII for example (I realize this is not a C idiom), it really becomes a non-issue if you have things scoped properly. For everything that doesn’t fit into this box you probably wouldn’t be relying on a GC anyway, the GC may do the final memory reap but scope control is still often manual in memory-managed languages.
- einpoklum 7y agoThat's not entirely true. If you only rely on RAII you may end up with millions of shared pointers, each of which needs to be managed independently and having its own overhead. They may also be independently allocated, which means they will be fragmented in memory. Not so simple.
- flatline 7y agoI think it’s safe to say for the general case that if you have millions of widely-shared smart pointers you are not following RAII principles. At that point you are left with poorly-implemented reference counting, with a ton of synchronization overhead.
- deleted 7y ago[deleted]
- einpoklum 7y agoWhich RAII principle would you say would be broken in this scenario?
- flatline 7y agoIf the lifetime of your objects are not bound to any scope, I’d say you’re well out of the realm of any real benefit that RAII would provide over GC. This is a continual problem that arises with a shared ownership model. The specific principle this violates is encapsulation - there is still encapsulation at the level of the smart pointer, but not with its consumers.
- ncmncm 7y agoIndeed, if you have a noticeable number of shared pointers, you are Doing It Wrong. A few here and there at top level are harmless, but if they have leaked into public interfaces or low-level infrastructure, you might better pitch the whole codebase and start over.