6 ms·

To clarify, it's up to the function being called; the convention set by Zig's standard library is that if a function needs to allocate memory, then the allocato

To clarify, it's up to the function being called; the convention set by Zig's standard library is that if a function needs to allocate memory, then the allocator (specifically, a struct of function pointers to an allocator's implementations of realloc and shrink) should be one of the function's arguments. There is of course nothing stopping a function from ignoring this and using the C global allocator if need be (or, as I've done in some experiments, using a C library's custom allocator - in my case that of SQLite). (EDIT: from what I understand, there's technically nothing stopping C from using this sort of strategy, either; a struct of function pointers ain't exactly exotic. It's just a matter of libraries being written with that convention in mind, which doesn't seem to be very common.)

glandium 6y ago
Oh so it has, in fact, the same caveat as Rust's scheme. Edit: I guess the difference is that Zig doesn't have years of not supporting it, making the ecosystem more prone to support it.
roca 6y ago
In a large complex application you are going to want to use the same allocator everywhere, or close to everywhere, and almost all functions may allocate memory directly or indirectly, in which case this Zig convention will require most every function to have a useless parameter. That sounds enraging.
- tjalfi 6y ago
  It's common to use multiple allocators in some domains; game developers often use a bump allocator[0] which is reset at the end of every frame. [0] https://twitter.com/SebAaltonen/status/1080235671883841541 https://twitter.com/SebAaltonen/status/1080235671883841541
  - roca 6y ago
    Thanks, that's a good counterexample.
- yellowapple 6y ago
  A large complex application seems like exactly the kind of environment where being stuck with a single allocator would be enraging. I personally like the idea of being able to give each component of a large system its own fixed chunk of memory (and an allocator over that chunk), such that if one component goes crazy with memory consumption it's isolated to that component instead of choking out the whole system.
  - roca 6y ago
    That makes a little bit of sense if by "component" you mean not a software component but a unit of work users care about (e.g. a document).
    - yellowapple 6y ago
      It's applicable in either case: - As you mentioned, if I'm editing a document, it's useful to have an allocator on a chunk of memory dedicated to that document. When I close the document, I can then simply free that chunk of memory - and everything allocated against it. - If I'm implementing an operating system, I'm probably going to want to give each application, driver, etc. a limited amount of memory to use and an allocator against that memory, both so that I can free a whole process at once when it terminates and so that a single process can't gobble up memory unless my operating system specifically grants it more to use (i.e. by itself allocating more memory and making the process' allocator aware of it).
      - roca 6y ago
        > When I close the document, I can then simply free that chunk of memory - and everything allocated against it. You probably don't want to do this directly. Instead you want to walk the object graph and run cleanup code for everything in that graph, because in general there will be resources that aren't just memory that need to be released, and for consistency with normal operation, it should deallocate memory as it goes. You probably don't want to allocate an actual "chunk of memory" either. That just creates unnecessary fragmentation. All you really need is accounting and the ability to report when you're consuming too much memory. Your driver example is not an example where you would allocate memory per software component. You would actually want to allocate per device, not per driver module; it's just confusing because in many cases there is only one device. But if you can plug in many devices that use the same driver, you'd want independent allocation accounting per device.

glandium 6y ago

Oh so it has, in fact, the same caveat as Rust's scheme. Edit: I guess the difference is that Zig doesn't have years of not supporting it, making the ecosystem more prone to support it.

roca 6y ago

In a large complex application you are going to want to use the same allocator everywhere, or close to everywhere, and almost all functions may allocate memory directly or indirectly, in which case this Zig convention will require most every function to have a useless parameter. That sounds enraging.

tjalfi 6y ago
It's common to use multiple allocators in some domains; game developers often use a bump allocator[0] which is reset at the end of every frame. [0] https://twitter.com/SebAaltonen/status/1080235671883841541 https://twitter.com/SebAaltonen/status/1080235671883841541
- roca 6y ago
  Thanks, that's a good counterexample.
yellowapple 6y ago
A large complex application seems like exactly the kind of environment where being stuck with a single allocator would be enraging. I personally like the idea of being able to give each component of a large system its own fixed chunk of memory (and an allocator over that chunk), such that if one component goes crazy with memory consumption it's isolated to that component instead of choking out the whole system.
- roca 6y ago
  That makes a little bit of sense if by "component" you mean not a software component but a unit of work users care about (e.g. a document).
  - yellowapple 6y ago
    It's applicable in either case: - As you mentioned, if I'm editing a document, it's useful to have an allocator on a chunk of memory dedicated to that document. When I close the document, I can then simply free that chunk of memory - and everything allocated against it. - If I'm implementing an operating system, I'm probably going to want to give each application, driver, etc. a limited amount of memory to use and an allocator against that memory, both so that I can free a whole process at once when it terminates and so that a single process can't gobble up memory unless my operating system specifically grants it more to use (i.e. by itself allocating more memory and making the process' allocator aware of it).
    - roca 6y ago
      > When I close the document, I can then simply free that chunk of memory - and everything allocated against it. You probably don't want to do this directly. Instead you want to walk the object graph and run cleanup code for everything in that graph, because in general there will be resources that aren't just memory that need to be released, and for consistency with normal operation, it should deallocate memory as it goes. You probably don't want to allocate an actual "chunk of memory" either. That just creates unnecessary fragmentation. All you really need is accounting and the ability to report when you're consuming too much memory. Your driver example is not an example where you would allocate memory per software component. You would actually want to allocate per device, not per driver module; it's just confusing because in many cases there is only one device. But if you can plug in many devices that use the same driver, you'd want independent allocation accounting per device.