Am 24.02.2014 17:35, schrieb Dicebot:
On Mon, 24 Feb 2014 17:03:23 +0100, Sönke Ludwig wrote:
You mean GC allocated. Using a free list based allocator for example,
surely is fast enough. What's missing is a way to use manual allocators
for exceptions (safely, more or less).It is not that simple. Problem is de-allocation - for raw classes destruction is not determenistic so there is no hook to call "allocator.free". Asking user to do it manually goes against safety concerns. Wrapping inside ref-counted struct can be an option but then you can't catch base classes because structs are not polymorphic.
That's what I meant with "What's missing is a way to use manual
allocators for exceptions (safely, more or less)".
I honestly don't know what a safe and performant solution can be here.
ARC support for classes as discussed some time ago would be a
possibility. Special support for throwing RefCounted!Exception could
be another option - with proper support for polymorphism, but
unfortunately that would require different catch statements for ref
counted exceptions and for normal ones, so it would be more of a hack
than a solution.
If I ever considered using vibe.d for perfomance-critical project, I'd likely just fork it and provide status codes based rendering alternative. But that is not a solution you are loking for :)
You can just set HTTPServerResponse.statusCode instead of throwing a HTTPStatusException, no need to fork anything. And as said, I intend
to avoid the exception for the 404 status case, too.