On Tuesday, 17 June 2014 at 19:28:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
Why wouldn't it? I thought that was the whole point of Andrei's
work on
std.allocator, specifically, a pool allocator. You allocate a
pool at
the beginning of an iteration, and it can be as simple as a
bump-the-pointer allocator inside the pool, then at the end of
the
iteration you free the entire pool all at once.
One key difference is that iOS is a controlled framework and
Apple ARC presumes that you only allocate a modest amount of ARC
objects per event. So you have to take special care if you
allocate lots of memory per event (create your own pools).
AFAIK, Apple-style ARC is only safe to use if you don't treat it
as an optional library solution. The AutoReleasePool does not
free the entire pool, only the ones that have a retain-count of
1. The basic idea is that you don't have to match up the initial
allocation-retain() with a release(). So I believe the codegen
only have to do retain()/release() when an ARC object might
escape the "event handler" call chain…
Sure, you can do it for D, but you have to deal with additional
issues (compared to GC).
