I was creating custom traking allocators in my C projects, so I am happy Odin has default one. Also basically Odin is a language that one to one reflects the way I program in C. Really happy that I found it.
"basically Odin is a language that one to one reflects the way I program in C" I agree with this so much. I used to have lots of boilerplatey code in C to make it work in a certain way, Odin just implements almost exactly all those things in the exact way that I wanted.
Nice that you are enjoying Odin. For me personally, as someone who is very comfortable with C programming, it all begins with the memory and my style of programming is to allocate large chunks on startup and manage them via custom allocators. Things are never really freed until program exit. Instead, depending on the use case, things are "freed" i.e. made available again to be used. I tried to do the same with Odin and it ends up being quite...strange. Maybe that's just me feeling uncomfortable with Odin which is quite different from C. What does draw me to Odin is the out of box Unicode support, strings, built in dynamic arrays and maps. I like pointer arithmetic so it will take me a long time to work with "slices". C's memory management is far simpler to use and so I still prefer C but every now and then I do try and re-implement what I am doing in Odin. I also noticed that the Odin allocator only accepts int for sizes rather than C's size_t. Does Odin's int automatically scale to 64bit depending on your architecture? Personally I would have preferred to use u64 but Odin forces me to cast all ints to u64 then.
You should be able to do the same with Odin. You can make a custom allocator that uses a pre-allocated memory blob. There are also arena allocators that can use pre-allocated memory blobs. You are correct that int is same size as the pointer size on the platform. So int on a 64 bit machine is an i64
@@karl_zylinski Yes, I am playing around with creating a few mem.Allocator { procedure: , data: }. as part of the global scope so I can just choose which allocator I want to use anywhere in the code base (frame_allocator, general_allocator, etc).
This allocator is awesome. Only difference for me is I format the error strings to be in the style of the odin compiler so my sublime build system picks them up and treats them like any other error; double-click to go to the error line and error tags displayed in the editor.
Have been making some good progress with odin and rl thanks to your videos - however, I noticed I have a memory leak and so used your method with the tracking allocator - I am getting multiple leaks detected when using the append() function and dynamic arrays. I can't figure out what I'm doing wrong yet, almost everything is stored on the stack or in a state struct - so not doing any manual allocations.. perhaps I am misunderstanding dynamic arrays and that they are always allocated and need discarding manually. Ironic that I'm using odin to escape dealing with C arrays... Cheers
You need to run delete(your_dynamic_array) to free the memory append(&your_dynamic_array, item) will dynamically allocate memory if it needs to grow. Only things that are of 'fixed' size is known at compile time. Dynamic arrays can grow and shrink during runtime, so they need manually allocated memory. Which allocator does the dynanmic array use? If not set then it will use context.allocator on the first call to append() But you can also specify when creating a dynamic array by running my_dynamic_array = make([dynamic]MyItemType, some_other_allocator) (here you can for example use context.temp_allocator if you don't need the memory in the long run)
@@karl_zylinski I'm sure I was using them unsafely(skill issue) I think the issue was in creating temp dynamic arrays and then assigning them to structs array := [dynamic]thing thing2.array = array which I thought was just a stack variable which would be freed once leaving scope but I think when you assign an array that way it just makes a reference to the original?? While I learn more about dynamic arrays I have just made all arrays fixed size for now which fixed the leaking issue Thanks for your help, odin and raylib are an awesome combo
@@karl_zylinski still had a memory leak when initially creating a state.entities array - which was once only on initialization added delete(state.entities) when the game quits and removed the leak definitely need to manage dynamic arrays properly sorry for the tech support on your channel :) !
I was creating custom traking allocators in my C projects, so I am happy Odin has default one. Also basically Odin is a language that one to one reflects the way I program in C. Really happy that I found it.
"basically Odin is a language that one to one reflects the way I program in C"
I agree with this so much. I used to have lots of boilerplatey code in C to make it work in a certain way, Odin just implements almost exactly all those things in the exact way that I wanted.
I love these shorter and focused format videos in addition to the longer more detailed ones!
what would be nice is a stack trace too. Knowing where the alloc is 50% but the other half is HOW it got there.
You can get a backtrace using this, it has an example of how to setup a tracking allocator that gets back traces github.com/laytan/back
This went over my head..Is there a video that teaches the basics of contexts and allocators?
Nice that you are enjoying Odin. For me personally, as someone who is very comfortable with C programming, it all begins with the memory and my style of programming is to allocate large chunks on startup and manage them via custom allocators. Things are never really freed until program exit. Instead, depending on the use case, things are "freed" i.e. made available again to be used. I tried to do the same with Odin and it ends up being quite...strange. Maybe that's just me feeling uncomfortable with Odin which is quite different from C.
What does draw me to Odin is the out of box Unicode support, strings, built in dynamic arrays and maps. I like pointer arithmetic so it will take me a long time to work with "slices". C's memory management is far simpler to use and so I still prefer C but every now and then I do try and re-implement what I am doing in Odin.
I also noticed that the Odin allocator only accepts int for sizes rather than C's size_t. Does Odin's int automatically scale to 64bit depending on your architecture? Personally I would have preferred to use u64 but Odin forces me to cast all ints to u64 then.
You should be able to do the same with Odin. You can make a custom allocator that uses a pre-allocated memory blob. There are also arena allocators that can use pre-allocated memory blobs.
You are correct that int is same size as the pointer size on the platform. So int on a 64 bit machine is an i64
@@karl_zylinski Yes, I am playing around with creating a few mem.Allocator { procedure: , data: }. as part of the global scope so I can just choose which allocator I want to use anywhere in the code base (frame_allocator, general_allocator, etc).
:0
very helpful, thank you!
This is very cool! Thanks for sharing it. I'll consider using something like this. :)
This allocator is awesome. Only difference for me is I format the error strings to be in the style of the odin compiler so my sublime build system picks them up and treats them like any other error; double-click to go to the error line and error tags displayed in the editor.
I actually do this too in my own code! I think the one I showed in video was from overview
Have been making some good progress with odin and rl thanks to your videos - however, I noticed I have a memory leak and so used your method with the tracking allocator - I am getting multiple leaks detected when using the append() function and dynamic arrays. I can't figure out what I'm doing wrong yet, almost everything is stored on the stack or in a state struct - so not doing any manual allocations.. perhaps I am misunderstanding dynamic arrays and that they are always allocated and need discarding manually. Ironic that I'm using odin to escape dealing with C arrays...
Cheers
You need to run
delete(your_dynamic_array) to free the memory
append(&your_dynamic_array, item) will dynamically allocate memory if it needs to grow.
Only things that are of 'fixed' size is known at compile time. Dynamic arrays can grow and shrink during runtime, so they need manually allocated memory.
Which allocator does the dynanmic array use? If not set then it will use context.allocator on the first call to append()
But you can also specify when creating a dynamic array by running my_dynamic_array = make([dynamic]MyItemType, some_other_allocator) (here you can for example use context.temp_allocator if you don't need the memory in the long run)
@@karl_zylinski
I'm sure I was using them unsafely(skill issue)
I think the issue was in creating temp dynamic arrays and then assigning them to structs
array := [dynamic]thing
thing2.array = array
which I thought was just a stack variable which would be freed once leaving scope
but I think when you assign an array that way it just makes a reference to the original??
While I learn more about dynamic arrays I have just made all arrays fixed size for now which fixed the leaking issue
Thanks for your help, odin and raylib are an awesome combo
@@karl_zylinski still had a memory leak when initially creating a state.entities array - which was once only on initialization
added delete(state.entities) when the game quits and removed the leak
definitely need to manage dynamic arrays properly
sorry for the tech support on your channel :) !