August 16, 2021

On Monday, 16 August 2021 at 05:47:10 UTC, Mathias LANG wrote:

>

On Monday, 16 August 2021 at 05:36:07 UTC, Tejas wrote:

>

That is why I was using heapAllocate, because using new on scope allocates exception on stack, and if you exit, then the exception is basically freed before it even gets caught. It fails even when you catch within the same function.

But allocate on heap and giving ownership to a scope qualified variable is no problem at all. No signal 11 killing my process ^_^

You are relying on an accept-invalid though. The compiler should not accept that code, but currently erroneously does so.

okay that's it, the following is my final try for this thing:

import std;
import core.lifetime:emplace;
import core.stdc.stdlib:malloc,free;

T heapAllocate(T, Args...)(Args args)@nogc{
    auto size = __traits(classInstanceSize, T);
    auto memory = malloc(size)[0 .. size];
    auto instance = emplace!(T,Args)(memory, args);
    return instance;
}

void throws()@nogc{
    auto/*no more scope*/ a = heapAllocate!(Exception)("works fine with scope, apparently");
    throw a;
}


void main()@nogc
{
    try{
        throws();
    } catch(Exception exp){
        scope(exit)free(cast(void*)exp);//new code
        printf("%s", cast(char*)exp.msg);
    }
}

There are 0 problems with this, right? I just have to remember to free the exception in the catch?

August 16, 2021

On Monday, 16 August 2021 at 06:12:14 UTC, Tejas wrote:

>

...

Fyi, check out std.exeprimental.allocator package. You can use allocators from there to do allocation of exceptions, on the heap or any other region.

August 16, 2021

On Monday, 16 August 2021 at 06:17:22 UTC, Alexandru Ermicioi wrote:

>

On Monday, 16 August 2021 at 06:12:14 UTC, Tejas wrote:

>

...

Fyi, check out std.exeprimental.allocator package. You can use allocators from there to do allocation of exceptions, on the heap or any other region.

Yes, I know about Mallocator. would've been nice to be able to do it just via the language and runtime features that are @nogc. And I'll have to do deallocation manually with that as well anyways.

When transpiling the C++ code, I really don't want to mix standard libraries, hence the desire to keep things contained just to the compiler/runtime as much as possible.

Of course, things like Octal are going to force me to use phobos anyways, so I'm thinking to just introduce a new scope and import these packages there in order to prevent names from clashing, but I also don't want an excessive amount of {...} littering the transpiled code...
Ah, I'll see to all this later, thank you very much for your time, everyone

1 2 3
Next ›   Last »