I'm currently trying to write a personal Associate Array class that can be used in @nogc sections. Obviously, this means I'll want to use malloc/free, however I'm not sure what the "Correct" way to do this is. In a few places online I've seen code for custom "_new" and "_delete" functions similar to this:

[code]
T _new(T, Args...) (Args args) {
    size_t objSize;
	static if(is (ValType == class))
	    objSize = __traits(classInstanceSize, T);
	else
	    objSize = T.sizeof;

    void* tmp = core.stdc.stdlib.malloc(objSize);
    if (!tmp) throw new Exception("Memory allocation failed");
    void[] mem = tmp[0..objSize];
    T obj = emplace!(T, Args)(mem, args);
    return obj;
}

void _delete(T)(T obj) {
    clear(obj);
    core.stdc.stdlib.free(cast(void*)obj);
}
[/code]

The Exception obviously uses the GC, and would need to be replaced with a printf or something; however, emplace doesn't have a @nogc replacement that I know of. What I'd like to know, from people much more knowledgeable about the ins and outs of D, is what the "Best" or "Correct" way to allocate and deallocate within @nogc sections?

PS: Tangentially related, what hashing algorithm does D use? I've seen people suggest using typeid(object).toHash(&object); however, toHash isn't @nogc, so I need to write my own Hashing function. For the sake of consistency and peace of mind, I'd really like to match mine as closely to Ds internal one as possible.

I realized the above "_new" has an issue with emplace depending on whether it's a class (reference type) or not. Class c = emplace() works, but something like string s = emplace() does not. Is doing string s = *emplace() safe and okay? Or is there a better way to handle the differences between allocating a Class with malloc vs a non-Class?

On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
> I'm currently trying to write a personal Associate Array class that can be used in @nogc sections. Obviously, this means I'll want to use malloc/free, however I'm not sure what the "Correct" way to do this is. In a few places online I've seen code for custom "_new" and "_delete" functions similar to this:
>
> [code]
> T _new(T, Args...) (Args args) {
>     size_t objSize;
> 	static if(is (ValType == class))
> 	    objSize = __traits(classInstanceSize, T);
> 	else
> 	    objSize = T.sizeof;
>
>     void* tmp = core.stdc.stdlib.malloc(objSize);
>     if (!tmp) throw new Exception("Memory allocation failed");
>     void[] mem = tmp[0..objSize];
>     T obj = emplace!(T, Args)(mem, args);
>     return obj;
> }
>
> void _delete(T)(T obj) {
>     clear(obj);
>     core.stdc.stdlib.free(cast(void*)obj);
> }
> [/code]
>
> The Exception obviously uses the GC, and would need to be replaced with a printf or something; however, emplace doesn't have a @nogc replacement that I know of. What I'd like to know, from people much more knowledgeable about the ins and outs of D, is what the "Best" or "Correct" way to allocate and deallocate within @nogc sections?
>
> PS: Tangentially related, what hashing algorithm does D use? I've seen people suggest using typeid(object).toHash(&object); however, toHash isn't @nogc, so I need to write my own Hashing function. For the sake of consistency and peace of mind, I'd really like to match mine as closely to Ds internal one as possible.

This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.

On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
> The Exception obviously uses the GC, and would need to be replaced with a printf or something; however, emplace doesn't have a @nogc replacement that I know of. What I'd like to know, from people much more knowledgeable about the ins and outs of D, is what the "Best" or "Correct" way to allocate and deallocate within @nogc sections?

This issue, as well as

> PS: Tangentially related, what hashing algorithm does D use? I've seen people suggest using typeid(object).toHash(&object); however, toHash isn't @nogc, so I need to write my own Hashing function. For the sake of consistency and peace of mind, I'd really like to match mine as closely to Ds internal one as possible.

this one, are related to the loss of guarantee attributes when using TypeInfo methods, most recently discussed in this thread[1]. It is essentially a bug, and a work in progress.

The correct way to handle OOM in D is to call core.exception.onOutOfMemoryError:

---
if (auto p = malloc(...))
    /* use p */
else
    onOutOfMemoryError(); // Throws OutOfMemoryError without allocating memory
---

[1] http://forum.dlang.org/post/krccldftrbbczahasvbi@forum.dlang.org

On Friday, 13 February 2015 at 05:56:37 UTC, Jakob Ovrum wrote:
> This issue, ... [is] related to the loss of guarantee attributes when using TypeInfo methods, most recently discussed in this thread[1]. It is essentially a bug, and a work in progress.

I see. So, in theory, after some patching emplace(), onOutOfMemoryError() and
toHash() should all work in @nogc sections?

If this is the case, Foo's m3.d module looks rather helpful, and
should tide me over until this fix is released; though, I'll be
honest when I say that I don't know how idiomatic or "correct"
Foo's implementation is.

On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
> This is something I've done recently.
> Would be glad if my code will help you:
> https://github.com/Dgame/m3
> Especially the m3.d module could be useful for you.

/* Class and Struct */

emplace: You can't assume zero-initialization for structs.
destruct: Is not memory-safe, and must not be marked @trusted.

/* Array */

make: You can't assume zero-initialization. T.sizeof is not the size of an element.
reserve: Not safe (you're freeing the old memory), must not be @trusted.
append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`.
destruct: Not safe, must not be @trusted.

On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>> This is something I've done recently.
>> Would be glad if my code will help you:
>> https://github.com/Dgame/m3
>> Especially the m3.d module could be useful for you.
>
> /* Class and Struct */
>
> emplace: You can't assume zero-initialization for structs.
> destruct: Is not memory-safe, and must not be marked @trusted.
>
> /* Array */
>
> make: You can't assume zero-initialization. T.sizeof is not the size of an element.
I'm aware of that.
> reserve: Not safe (you're freeing the old memory), must not be @trusted.
> append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`.
> destruct: Not safe, must not be @trusted.
Ah, that is nice to know. I will fix this soon. Or would you help me out with an PR?

Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.

On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
> Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.

As it is right now, I fear it may do more harm than good.

On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote:
> On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
>> Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.
>
> As it is right now, I fear it may do more harm than good.

Always the same in this newsgroup. You want to help as good as you can (even if it's not perfect) and all you get are subliminal messages... :)

I'm regret that I tried to help, I will delete this repo as far as possible. :)

On Friday, 13 February 2015 at 23:29:11 UTC, Foo wrote:
> On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote:
>> On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
>>> Don't understand me wrong. My code is not perfect, but maybe it can be helpful for someone.
>>
>> As it is right now, I fear it may do more harm than good.
>
> Always the same in this newsgroup. You want to help as good as you can (even if it's not perfect) and all you get are subliminal messages... :)
>
> I'm regret that I tried to help, I will delete this repo as far as possible. :)

Please don't do that. Even if the code has some errors, it was a helpful and useful module I can work with. I'm sure others may feel the same way =)

Stick and Stones.