Swift does away with pointers == pervasive ARC

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 17, 2014 at 07:19:54PM +0000, via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 18:39:46 UTC, Walter Bright wrote:
> >If an app can be cheaply restarted, an easy & fast way to do memory
> >allocation is to use a "bump allocator" like dmd does, and then
> >restart when it runs out of memory.
> >
> >I'm not joking, this can actually be very practical for certain kinds
> >of programs.
> 
> I think it was common to use a region allocator in ray tracing, per
> ray-path. Meaning you calculate the worst case memory consumption and
> malloc one big block (or put it in a segment in the exec), then just
> move a pointer ahead for allocations, and reset the pointer before you
> fire the next ray from the camera.
> 
> iOS ARC do use Autorelease Pool Blocks which takes care of release()
> at the end of the event loop. That probably affects ARC
> implementation/code gen. It basically means that you don't release
> allocated memory except at the end of an iteration. That won't work
> very well in D though?
[...]

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. Presumably Andrei would
come up with some way of making sure that built-in constructs like ~
would allocate from the pool instead of the GC heap, then you don't even
need to restrict the code that runs inside each iteration.


T

-- 
Famous last words: I wonder what will happen if I do *this*...