On Wednesday, 17 February 2016 at 06:52:21 UTC, thedeemon wrote:
> So keep GC heap for small litter (including exceptions) and use other allocators for large pieces of data. This way you may get best of what D offers without long-GC-pause or out-of-memory-termination pains.

I will probably do that. Since others said I can actually catch that out of memory error and that the destructors will run (and thus free some of the resources) I see no problem in writing it in D. I am happy it doesn't force abort()s as some other languages (rust) or libraries (glib). Thank you everyone for answering my questions and consider this solved (where can I mark it as such?).

On Wednesday, 17 February 2016 at 14:01:17 UTC, Jardík wrote:

> consider this solved (where can I mark it as such?).

The forum is a web fronted for a news server. No such feature.

On Wed, 17 Feb 2016 01:09:20 +0000, Adam D. Ruppe wrote:

> On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright wrote:
>> http://dpldocs.info/search/search?searchTerm=emplace to create an exception object in manually allocated memory.
> 
> Aye, this overload: http://dpldocs.info/experimental-docs/std.conv.emplace.3.html
> 
> though the example there is awful, wtf is it even trying to show?
> 
> 
> But anyway, you can also throw a static object. That's actually what
> outOfMemoryError does
> <http://dpldocs.info/experimental-docs/
core.exception.onOutOfMemoryError.html>
> - it throws a statically allocated object.

Sure, but that's pretty annoying. You have to ensure that you will never need to throw two of the same exception at the same time -- or you allocate several statically and go through hoops to ensure you're using one that's not currently in use.

It's a lot easier to malloc and free exceptions. Since they're presumably only cropping up in exceptional circumstances, there's a lot less worry about making many small allocations.

On Wed, 17 Feb 2016 02:24:51 +0000, cym13 wrote:

> On Wednesday, 17 February 2016 at 02:23:34 UTC, cym13 wrote:
>> Such errors are static errors, they aren't allocated on the stack, a 128 bytes buffer is shared accross threads to keep them.
> 
> Sorry, of course I meant they *are* allocated on the stack.

In the context of exceptions, you can't allocate them on the stack at the point at which you throw them. As soon as you throw them, the stack frame is invalidated (to run destructors for stack-scoped items, possibly other things), so your exception object is at least moderately likely to be corrupted.

You *could* allocate them on the stack in, say, main(), but then you'd have to pass a reference to them down the stack somehow. Kind of awkward.

On Wednesday, 17 February 2016 at 01:09:20 UTC, Adam D. Ruppe wrote:
> On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright wrote:
>> http://dpldocs.info/search/search?searchTerm=emplace to create an exception object in manually allocated memory.
>
> Aye, this overload: http://dpldocs.info/experimental-docs/std.conv.emplace.3.html
>
> though the example there is awful, wtf is it even trying to show?

I guess it is primarily supposed to be a unittest to verify that emplace works with interfaces...