4 ms·

> There is no global allocator in Zig > Zig has a global allocator that you’re encouraged to use wat

sundarurfriend 4y ago
You left out a whole paragraph of context to the second statement, and especially chose to cut off even the beginning and end of that sentence: > By convention, Zig has a global allocator that you’re encouraged to use for all your unit tests If you read sentences in bits and pieces by themselves, you'll find that it does lead to a lot of misinterpretation.
cassepipe 4y ago
I suspect this means that the Zig stdlib does not use a default allocator but Zig provides a default allocator that you have to intentionnally use in your functions if you want to allocate. Is this correct ?
- P5fRxh5kUvp2th 4y ago
  This is correct, with the caveat that I believe zig provides several different allocators that you can pick and choose for various situations. so the word 'default' may not necessarily apply the way it doesn't apply wrt to 'default pointer' in C++ because it offers both unique_ptr and shared_ptr with very different behaviors and semantics.
flohofwoe 4y ago
There is no hidden implicit allocator used by the language or stdlib (like in Rust or C++), instead every stdlib API that allocates requires an allocator either in an initialization function, or as argument on individual functions. The stdlib then provides a variety of allocator implementations that can be plugged into those allocator arguments.
- messe 4y ago
  To add to that, it's also idiomatic for external libraries in Zig to take an allocator as arguments, rather than using the libc's malloc like a lot of C libraries do.
  - girvo 4y ago
    Which as an aside, is a lovely feature when you’re doing things like working with external SPI PSRAM and rightfully want to treat it differently to your local SRAM in embedded applications. We didn’t use Zig for our firmware, but we did come up with a similar approach in Nim (basically a neat type that takes allocators/frees/reallocs and handles managing the ref count so you can use the variable as any other Nim variable. It’s not perfect, but close enough for our purposes)
ikskuh 4y ago
This is sadly very badly worded. Zig provides a global allocator when running tests that will check for memory leaks and double frees. This allocator is only available in the test suite tho, if you want to compile an executable, one has to chose between several allocators and instantiate them explicitly. There are three allocators that are globally available in the standard library: - `std.heap.c_allocator`, a wrapper around malloc/free. only available when linking libc - `std.heap.page_allocator`, a wrapper around VirtualAlloc/mmap. Can only allocate in OS page size granularity and is quite slow. A good backing for other allocators tho. - `std.testing.failing_allocator`, an allocator that will always yield OutOfMemory. For the use in an application, there's the std.heap.GeneralPurposeAllocator type that needs to be explicitly instantiated, and it provides a good portion of debugging features right now. High-speed implementations are planned for release modes
boltzmann-brain 4y ago
Came to point this out... I don't think I trust these people to write my compiler.

You left out a whole paragraph of context to the second statement, and especially chose to cut off even the beginning and end of that sentence: > By convention, Zig has a global allocator that you’re encouraged to use for all your unit tests If you read sentences in bits and pieces by themselves, you'll find that it does lead to a lot of misinterpretation.

cassepipe 4y ago

I suspect this means that the Zig stdlib does not use a default allocator but Zig provides a default allocator that you have to intentionnally use in your functions if you want to allocate. Is this correct ?

P5fRxh5kUvp2th 4y ago
This is correct, with the caveat that I believe zig provides several different allocators that you can pick and choose for various situations. so the word 'default' may not necessarily apply the way it doesn't apply wrt to 'default pointer' in C++ because it offers both unique_ptr and shared_ptr with very different behaviors and semantics.

flohofwoe 4y ago

There is no hidden implicit allocator used by the language or stdlib (like in Rust or C++), instead every stdlib API that allocates requires an allocator either in an initialization function, or as argument on individual functions. The stdlib then provides a variety of allocator implementations that can be plugged into those allocator arguments.

messe 4y ago
To add to that, it's also idiomatic for external libraries in Zig to take an allocator as arguments, rather than using the libc's malloc like a lot of C libraries do.
- girvo 4y ago
  Which as an aside, is a lovely feature when you’re doing things like working with external SPI PSRAM and rightfully want to treat it differently to your local SRAM in embedded applications. We didn’t use Zig for our firmware, but we did come up with a similar approach in Nim (basically a neat type that takes allocators/frees/reallocs and handles managing the ref count so you can use the variable as any other Nim variable. It’s not perfect, but close enough for our purposes)

ikskuh 4y ago

This is sadly very badly worded. Zig provides a global allocator when running tests that will check for memory leaks and double frees. This allocator is only available in the test suite tho, if you want to compile an executable, one has to chose between several allocators and instantiate them explicitly. There are three allocators that are globally available in the standard library: - `std.heap.c_allocator`, a wrapper around malloc/free. only available when linking libc - `std.heap.page_allocator`, a wrapper around VirtualAlloc/mmap. Can only allocate in OS page size granularity and is quite slow. A good backing for other allocators tho. - `std.testing.failing_allocator`, an allocator that will always yield OutOfMemory. For the use in an application, there's the std.heap.GeneralPurposeAllocator type that needs to be explicitly instantiated, and it provides a good portion of debugging features right now. High-speed implementations are planned for release modes

boltzmann-brain 4y ago

Came to point this out... I don't think I trust these people to write my compiler.