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" > <[email protected]>" 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!
