Swift does away with pointers == pervasive ARC

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 12:04:33 PDT 2014


On Tue, Jun 17, 2014 at 11:39:50AM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/17/2014 11:25 AM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
> >On Tuesday, 17 June 2014 at 18:17:21 UTC, Walter Bright wrote:
> >>I wouldn't be surprised if it doesn't in order to make ARC more
> >>palatable.
> >
> >I don't know, but on iOS you are supposed to save state to disk
> >continuously so that the app can die silently and reboot to where you
> >left off. And mobile apps are supposed to boot real fast since they
> >are used on the move.
> >
> >So maybe they figured it was good enough to leave the try-catch
> >complexity out…
> 
> 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 don't think the user would enjoy the app "randomly" shutting down and
starting up again on him. :-)

One idea that occurs to me, though, is to split the app into a frontend
that does not allocate during runtime, and a backend, which may. Design
it in such a way that the backend can freely restart anytime without
adversely affecting the frontend; then you can maintain an apparance of
continuous execution across backend restarts.

If the restart time can be reduced to within a single animation frame,
for example, one could actually write a game engine that never
deallocates, it just restarts itself when it runs out of memory and the
frontend maintains the façade of continuous execution. This will trump
GC, ARC, malloc, indeed, any memory allocation scheme beyond
bump-a-pointer. :-P


T

-- 
That's not a bug; that's a feature!


More information about the Digitalmars-d mailing list