@nogc and exceptions

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 12 09:33:03 PDT 2014


12-Sep-2014 15:03, monarch_dodra пишет:
> I like the option of having "exception allocators" that can later be
> explicitly called in a "release all exceptions" style, or plugged into
> the GC, to be cleaned up automatically like any other GC allocated
> exception. This would make the exceptions themselves still @nogc, but
> the GC would have a hook to (potentially) collect them. For those that
> don't want that, then they can make calls to the cleanup at
> deterministic times.
>
> This, combined with the fact that we used an (unshared) allocator means
> the cleanup itself would be 0(1).
>
> Finally, if somebody *does* want to keep exceptions around, he would
> still be free to do so *provided* he re-allocates the exceptions himself
> using a memory scheme he chooses to use (a simple GC new, for example).
>
>
>
> ... well, either that, or have each exception carry a callback to its
> allocator, so that catch can do the cleanup, regardless of who did the
> allocation, and how. GC exceptions would have no callback, meaning a
> "catch" would still be @nogc. An existing code that escapes exceptions
> would not immediately break.
>
> Either way, some sort of custom (no-gc) allocator seems in order here.

Agreed.

I think that the total amount of live (not garbage) exceptions on heap 
is small for any typical application. Thus just special casing the hell 
out of exception allocation in the GC (and compiler) is IMO perfectly 
satisfactory hack.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list