2 ms·
"You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best." If I use the factory pattern with pre-
by Recurecur 11y ago
"You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best."
If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime.
"You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use)."
Wrong across the board.
- vardump 11y ago> If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. Weird you'd say that, exactly same applies to any garbage collected language.
- Recurecur 11y agoNo, the GC still periodically runs, polluting cache, consuming cycles and halting the rest of the program until it's done. The only exception is if you completely avoid allocations, which is generally next to impossible in GC based languages. With ARC, there is exactly zero overhead unless a new reference is created or destroyed. In that case there's an integer add or subtract, not a global "stop the world" kind of event.