On Wednesday, 13 July 2016 at 20:57:49 UTC, Lodovico Giaretta
wrote:
On Wednesday, 13 July 2016 at 20:44:52 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 16:28:23 UTC, Lodovico Giaretta
wrote:
It's actually quite easy. Here's the code (untested):
================================================================
import std.experimental.allocator.building_blocks.region;
import std.experimental.allocator.mallocator;
import std.experimental.allocator;
Region(shared(Mallocator)) exception_allocator;
enum EXCEPTION_MEM_SIZE = 256*1024;
static this()
{
exception_allocator =
typeof(exception_allocator)(EXCEPTION_MEM_SIZE);
}
================================================================
And here is an usage example (untested, too):
================================================================
void throwingFunction()
{
// try to do something, but fail
throw exception_allocator.make!Exception("my wonderful
error message");
}
void throwingThrowingFunction()
{
try
{
// try to call function, which fails
throwingFunction;
}
catch (Exception exc)
{
// try to recover from failure, but generate other
exception (just to show chaining)
throw exception_allocator.make!Exception("I love
exception chaining");
}
}
void main()
{
try
{
// try to call function, which fails
throwingThrowingFunction;
}
catch (Exception exc)
{
// recover from failure, then deallocate the
exceptions no longer needed
exception_allocator.deallocateAll;
}
}
================================================================
Doesn't work. identifier expected on shared.
What's the difference of simply using malloc to allocate the
memory and creating the exceptions their? Seems like a long
and winded way go about it or is there some benefit to using
the experimental allocators?
`Region(shared(Mallocator))` shall be `Region!(shared
Mallocator)` (again, I'm just looking at the code, didn't test
it).
The advantages over a simple malloc are:
1) You can change between GC allocation, malloc, mmap and other
allocators by changing a single line, instead of changing every
throw;
Ok, I like!
2) you can use very fast allocators, based on your needs; this
example uses the Region allocator, which is way faster than a
call to malloc;
I like too! But I'll have to assume you are right since I have no
proof.
3) the Region allocator has the added value of working even if
there's no more memory available (because it preallocated it).
Well, one could do this with malloc because one can pre-allocate
it too. I figure this is why you stated 2 though because it is
pre-allocated? So, really only point 1 stands, but that is
probably not even valid since one can wrap the allocator in a
template. This is probably exactly what is being done..
So, ultimately no real benefit except the implementation details
have been removed. That's not a bad thing as long as it works ;)
In general, the allocators library provides facilities that may
seem overkill for simple tasks (and in fact they are), but
prove very flexible and useful for advanced uses, or to write
generic highly customizable code.
Of course, being experimental, this library has still some
issues...
Well, I will try out the code and see. You've provided an example
and if it works then it should be good enough in my case. If it
doesn't limit what I need to do then I'm happy ;)
How is phobo's going to deal with such things when it is trying
to get off the GC? It surely has to throw exceptions. Similar
method or something entirely different?
Thanks.
