iPhone vs Android

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 13 15:19:54 PDT 2016

On Tuesday, September 13, 2016 14:43:09 Walter Bright via Digitalmars-d wrote:
> Case in point, exceptions. Currently exceptions are fairly wedded to being
> GC allocated. Some people have opined that this is a major problem, and it
> is if the app is throwing a lot of exceptions. But exceptions should be
> exceptional.
> There is still a place for GC, even in a high performance app. The
> all-or-nothing approach to using the GC is as wrong as any programming
> methodology is.

The big problem with exceptions being allocated by the GC isn't really the
GC but @nogc. Obviously, a program that does not use the GC at all can't
allocate an exception with the GC, but in general, I would fully expect that
even a program that allows the GC but uses it minimally would have no
problem with the garbage created by exceptions precisely because they should
be rare. 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), or you are _very_ careful with how you write that
code so that you can get away with malloc-ing the exception (but that
approach won't work in the general case unless you don't care about leaking
the memory from the exception, since most code would assume that the
exception was allocated by the GC and wouldn't know how to free it). So,
@nogc code is going to have a tendency to not use exceptions just because
exceptions don't work well without the GC. And those who want to use
exceptions and are willing to have their code not be @nogc will forgo @nogc
even when the code could have been @nogc otherwise.

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.

- Jonathan M Davis

More information about the Digitalmars-d mailing list