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;
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;
3) the Region allocator has the added value of working even if
there's no more memory available (because it preallocated it).
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...
