@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