iPhone vs Android

[H. S. Teoh via Digitalmars-d]

On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d wrote:
[...]
> But none of the code that's marked @nogc can throw an exception unless
> you're either dealing with pre-allocated exceptions (in which case,
> they're less informative),

I don't see why pre-allocated exceptions would be less informative. You
can always modify the exception object before throwing it, after all.
In fact, I've always wondered about the feasibility of a @nogc exception
handling system where the exception is emplaced onto a fixed static
buffer, so that no allocation (except at the start of the program) is
actually necessary. Of course, chained exceptions throw(!) a monkey
wrench into the works, but assuming we forego chained exceptions,
wouldn't this work around the problem of being unable to allocate
exceptions in @nogc code? (Albeit with its own limitations, obviously.
But it would be better than being unable to use exceptions at all in
@nogc code.)


[...]
> So, I really think that we need to find a way to make it so that
> exceptions aren't GC allocated normally anymore - or at least have a
> way to reasonably and easily not be GC allocated - but the problem is
> @nogc, not the actual memory management or its cost.
[...]

There's nothing about the 'throw' keyword that requires GC allocation.
It's just that `throw new Exception(...)` has become a standard
incantation. The exception object itself can, for example, be emplaced
onto a static buffer as I propose above.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser