Thread overview | |||||
---|---|---|---|---|---|
|
September 05, 2018 D's policy on hidden memory allocations and nothrow @nogc | ||||
---|---|---|---|---|
| ||||
After having read up on Zig's [1] policy for memory management, basically meaning no syntactically hidden memory allocations, I wonder if D has something similar. Is the praxis that _all_ containers and GC-allocations should throw a core.exception.OutOfMemoryError upon out of memory error? If so should all algorithms that potentially allocates memory be non-`nothrow`, and in turn, non-`@nogc`? And how does this relate to instead using `assert`s and DIP-1008? [1]: https://ziglang.org/ |
September 05, 2018 Re: D's policy on hidden memory allocations and nothrow @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Wednesday, 5 September 2018 at 20:53:41 UTC, Per Nordlöw wrote: > Is the praxis that _all_ containers and GC-allocations should throw a yeah, but do so via the onOutOfMemoryError function instead of "throw new" http://dpldocs.info/experimental-docs/core.exception.onOutOfMemoryError.html well, unless you actually have a recoverable out of memory situation, then you might want to do it differently (e.g. a pool runs out of memory, then you might return null or something and handle it at a higher level) But... > If so should all algorithms that potentially allocates memory be non-`nothrow`, and in turn, non-`@nogc`? No, it doesn't affect either of those. It doesn't affect @nogc because the function above will throw a statically-allocated object instead of creating a new one (if it is out of memory, where would it allocate a new one anyway?). It doesn't affect nothrow because it is considered a fatal Error instead of a recoverable Exception. > And how does this relate to instead using `assert`s and DIP-1008? assert works by similar rules and is thus unaffected by those things too. |
September 05, 2018 Re: D's policy on hidden memory allocations and nothrow @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Wednesday, 5 September 2018 at 21:06:07 UTC, Adam D. Ruppe wrote:
> It doesn't affect @nogc because the function above will throw a statically-allocated object instead of creating a new one (if it is out of memory, where would it allocate a new one anyway?).
>
> It doesn't affect nothrow because it is considered a fatal Error instead of a recoverable Exception.
>
>> And how does this relate to instead using `assert`s and DIP-1008?
>
> assert works by similar rules and is thus unaffected by those things too.
Thanks!
|
Copyright © 1999-2021 by the D Language Foundation