On Tuesday, 26 January 2016 at 13:56:39 UTC, Igor wrote:
> //ubyte[__traits(classInstanceSize, App)] buffer;
> auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize, App))[0..__traits(classInstanceSize, App)];
>
> works, so it is the ubyte line.
> 		

Can you please post the full code? From your description, it looks like the stack frame might get invalidated...

On Tuesday, 26 January 2016 at 13:56:39 UTC, Igor wrote:
>
> //ubyte[__traits(classInstanceSize, App)] buffer;
> auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize, App))[0..__traits(classInstanceSize, App)];
>
> works, so it is the ubyte line.
> 		

Make sure the buffer outlives the class instance.
If you emplace on the stack, then at the end of the scope your instance is gone.

On Tuesday, 26 January 2016 at 01:09:50 UTC, Igor wrote:
> Is there any examples that shows how to properly allocate an object of a class type with the new allocators and then release it when desired?

This is more or less the same answer as you've get previously except that I don't use emplace but rather a copy of what's done in _d_new_class() from the D runtime:

CT construct(CT, A...)(A a) @trusted @nogc
if (is(CT == class))
{
    import std.experimental.allocator.mallocator;
    auto size = typeid(CT).init.length;
    auto memory = Mallocator.instance.allocate(size); // D runtime use GC here
    memory[0 .. size] = typeid(CT).init[];
    static if (__traits(hasMember, CT, "__ctor"))
        (cast(CT) (memory.ptr)).__ctor(a);
    import core.memory: GC;
    GC.addRange(memory.ptr, size, typeid(CT));
    return cast(CT) memory.ptr;
}

the GC stuff could look superfluous but without this and if there's a GC allocated members in your class (even a simple dynamic array) then you'll encounter random errors at run-time.

On Wednesday, 27 January 2016 at 06:40:00 UTC, Basile B. wrote:
> On Tuesday, 26 January 2016 at 01:09:50 UTC, Igor wrote:
>> Is there any examples that shows how to properly allocate an object of a class type with the new allocators and then release it when desired?
>
> This is more or less the same answer as you've get previously except that I don't use emplace but rather a copy of what's done in _d_new_class() from the D runtime:
>
> CT construct(CT, A...)(A a) @trusted @nogc
> if (is(CT == class))
> {
>     import std.experimental.allocator.mallocator;
>     auto size = typeid(CT).init.length;
>     auto memory = Mallocator.instance.allocate(size); // D runtime use GC here
>     memory[0 .. size] = typeid(CT).init[];
>     static if (__traits(hasMember, CT, "__ctor"))
>         (cast(CT) (memory.ptr)).__ctor(a);
>     import core.memory: GC;
>     GC.addRange(memory.ptr, size, typeid(CT));
>     return cast(CT) memory.ptr;
> }
>
> the GC stuff could look superfluous but without this and if there's a GC allocated members in your class (even a simple dynamic array) then you'll encounter random errors at run-time.

Thanks.

But doesn't this ultimately defeat the purpose of having manual memory management if one has to add it to the GC to be scanned? Seems like it is just an extra step. The whole point is to prevent the GC from having to mess with the object in the first place. I understand if it uses GC based objects then the GC needs to be informed but this really feels like it defeats the purpose.

Ultimately I want no GC dependency. Is there an article that shows how this can be done?

On Wednesday, 27 January 2016 at 22:39:54 UTC, Igor wrote:
> Ultimately I want no GC dependency. Is there an article that shows how this can be done?

You can link with gcstub https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d it will replace GC completely.

On Wednesday, 27 January 2016 at 22:39:54 UTC, Igor wrote:
> But doesn't this ultimately defeat the purpose of having manual memory management if one has to add it to the GC to be scanned?

You can make the LOC related to the GC optional with an additional bool template parameter and a static if, but as said previously it can introduce bugs.

AddRange() is used to make the GC scan pointers inside the range (build-in array for example)) but the range is itself well manually managed.