Issue with free() for linked list implementation
Hello. I’m trying to write my own version of a list that doesn’t rely on the garbage collector. I’m working on a very bare bones implementation using malloc and free, but I’m running into an exception when I attempt to call free. Here is a very minimal code sample to illustrate the issue: // Some constant values we can use static const int two = 2, ten = 10; // Get memory for two new nodes Node* head = cast(Node*)malloc(two.sizeof); Node* node1 = cast(Node*)malloc(ten.sizeof); // Initialize the nodes node1.value = ten; node1.next = null; head.value = two; head.next = node1; // Attempt to free the head node Node* temp = head.next; head.next = null; free(head); // Exception right here head = temp; Note, if I comment out the line ‘head.next = node1’, this code works. Does anyone know what I’m doing wrong with my manual memory management?
Re: Issue with free() for linked list implementation
On Friday, 3 April 2015 at 22:06:06 UTC, Namespace wrote: On Friday, 3 April 2015 at 22:02:13 UTC, Kitt wrote: Hello. I’m trying to write my own version of a list that doesn’t rely on the garbage collector. I’m working on a very bare bones implementation using malloc and free, but I’m running into an exception when I attempt to call free. Here is a very minimal code sample to illustrate the issue: // Some constant values we can use static const int two = 2, ten = 10; // Get memory for two new nodes Node* head = cast(Node*)malloc(two.sizeof); Node* node1 = cast(Node*)malloc(ten.sizeof); // Initialize the nodes node1.value = ten; node1.next = null; head.value = two; head.next = node1; // Attempt to free the head node Node* temp = head.next; head.next = null; free(head); // Exception right here head = temp; Note, if I comment out the line ‘head.next = node1’, this code works. Does anyone know what I’m doing wrong with my manual memory management? Why did you allocate only 2 / 10 bytes and not Node.sizeof bytes? Since your Node struct has at least one pointer (nexT) and a value (I assume of type int) you must allocate at least 8 bytes for one Node. I'm sure that is at least one of your problems. Wow, I can't even begin to explain how red my cheeks are right now. You're completely right; I have no idea what my head was thinking. Sure enough, call malloc with the correct type, and the error goes away =P Thanks for the help =) I guess I've been in C# land at work for way too long now, my low level C skills are evaporating!
Re: What is the Correct way to Malloc in @nogc section?
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.
Re: What is the Correct way to Malloc in @nogc section?
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.
What is the Correct way to Malloc in @nogc section?
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.
Re: What is the Correct way to Malloc in @nogc section?
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?
