{"id":25385322,"url":"https://github.com/the-argus/allo","last_synced_at":"2025-04-09T16:28:33.860Z","repository":{"id":220717056,"uuid":"752381387","full_name":"the-argus/allo","owner":"the-argus","description":"A C++ library for making your code generic over allocation and alignment. Inspired by the Zig stdlib.","archived":false,"fork":false,"pushed_at":"2024-12-21T06:19:49.000Z","size":471,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-02-15T09:48:23.127Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/the-argus.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-02-03T19:06:10.000Z","updated_at":"2024-12-21T06:19:53.000Z","dependencies_parsed_at":"2024-02-11T20:53:17.660Z","dependency_job_id":"b8a83608-6370-4b1b-bafa-7e3dc24bd45b","html_url":"https://github.com/the-argus/allo","commit_stats":null,"previous_names":["the-argus/allo"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/the-argus%2Fallo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/the-argus%2Fallo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/the-argus%2Fallo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/the-argus%2Fallo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/the-argus","download_url":"https://codeload.github.com/the-argus/allo/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248067278,"owners_count":21042265,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-15T09:48:27.277Z","updated_at":"2025-04-09T16:28:33.835Z","avatar_url":"https://github.com/the-argus.png","language":"C++","readme":"# allo\n\nA C++ library for making your code generic over allocation and alignment.\nInspired by the Zig stdlib.\n\n**ALLO IS STILL EXPERIMENTAL.**\n\n## Allo Provides...\n\n1. `scratch_allocator_t`\n   - An object which allows you to allocate and to register destruction callbacks.\n     Upon destruction, it frees all of its allocations and calls callbacks. Not\n     threadsafe.\n2. `stack_allocator_t`\n   - Similar to the scratch allocator, but it allows you to remap and free\n     the topmost allocation. Not threadsafe.\n3. `heap_allocator_t`\n   - An object which lets you arbitrarily alloc and free memory. Its advantages\n     over `malloc` are that it defines exactly when it will make a syscall (by\n     default, it never does) and that it frees all of its allocations upon\n     destruction (as opposed to `malloc`, where you must remember to free each\n     induvidual allocation). Not threadsafe.\n4. `block_allocator_t`\n   - An optimization of `heap_allocator_t` for when all of your allocations may\n     be similarly sized. Not threadsafe.\n5. `c_allocator_t`\n   - A rough attempt to make `malloc` fit into the abstractions of this library.\n     Its primary use is as a quick-and-easy allocator which is unbounded except\n     by system memory/swap space, and can be passed into functions which might\n     otherwise be intended to accept the other four.\n   - Breaks the abstraction: you cannot remap allocations, nor register\n     destruction callbacks. Most importantly, *there is no way to free all of\n     the allocations made by this allocator, so it does nothing upon destruction.*\n6. Debugging features\n   - Runtime type info (rtti compiler option not required) to check if you freed\n     an allocation with a different type than you originally allocated it with\n   - Allocation size tracking, to ensure that you request frees as the same size\n     that you allocated them with.\n\n## Planned Features and Fixes\n\n1. A `template \u003ctypename T\u003e class threadsafe_t` to allow for threadsafe variants of\n   the heap allocators.\n2. `virtual_allocator_t`, `virtual_stack_allocator_t`, `virtual_heap_allocator_t`,\n   and `virtual_threadsafe_heap_allocator_t`. A class which can be extended with\n   virtual overrides to implement your own allocator and pass it to functions\n   which expect an allocator from this library. Probably an antipattern, as kind of\n   the whole point of Allo is that you only ever need stack, block, and heap\n   allocators.\n3. `debug_allocator_t` which internally uses `c_allocator_t`, but provides options\n   to make certain functions always fail. Effectively a limited shortcut and could be\n   achieved with the `virtual_threadsafe_heap_allocator_t`. May not be necessary.\n4. An `allo::make_unique` and `allo::make_shared` for use with the heap allocators.\n5. Debugging Options\n   - Disable runtime allocation type info and allocation size tracking by default,\n     allow enabling in debug mode or always. Encourage enabling both these features\n     in debug mode, and use them in example code. However it's important to understand\n     that these increase memory usage substantially before enabling them. Could cause\n     bugs that only occur in release mode.\n6. New Debugging Features\n   - Optionally allow refcounting *all* allocations, using a global threadsafe array\n     of refcounts. Would require for `zl::slice` to be overridden in debug mode to\n     implement the semantics of a shared pointer. Log error details whenever the\n     contents of a slice is accessed after free or before initialization. Probably\n     won't make it to first release but will require significant preparation to\n     ensure it can be added in later releases. Functions like `alloc_one` would need\n     to be rethought, since they return a `T\u0026` instead of a `zl::slice\u003cT\u003e`.\n   - Optionally allow allocator constructors to take in a logging callback.\n7. Allow for allocators to request new blocks of memory from their parent allocator\n   instead of only trying to remap their current block. Will allow for potentially\n   unbounded amounts of memory allocation, although will require some additional\n   memory usage for the allocator to keep track of the blocks it owns. May be\n   implemented as separate variants of the current allocators.\n8. Add some sort of API to allow for saving and then restoring the state of an\n   allocator, or easily registering a sub-allocator, so that procedures which\n   allocate can return an error and then the caller can easily undo any allocation\n   they may have performed.\n\n## Benefits\n\n- You know what memory is being allocated and how- the allocator is no longer global.\n- The details of memory allocation are hidden from systems. For example:\n  - switch out a `heap_allocator_t` with a `block_allocator_t` to decrease memory\n    usage for many similar sized allocations.\n  - switch out a `c_allocator_t` with a `stack_allocator_t` for routines which\n    only perform allocation, so that the allocations become contiguous\n\n## Why not STL polymorphic allocators?\n\nThe goal of allo is to provide a framing for programming problems where\nallocators handle most of the ownership within a program. This violates RAII\n(allocators, when destructed, do no call the destructors of items allocated\nwithin them).\n\nAdditionally, allo provides a slightly different model of allocators that the\nSTL. Where the STL has \"deleters\" and the fully fledged polymorphic allocators,\nallo has the following inheritance hierarchy:\n\n1. Allocator\n   - Able to allocate new memory\n   - Able to register \"destruction callbacks\". Used for non-memory resources.\n2. Stack Allocator\n   - Allocator with the additionl ability to:\n     - Free the most recently allocated allocation\n     - Realloc the most recently allocated allocation\n3. Heap Allocator\n   - Stack Allocator which is able to realloc/free _any_ allocation, not\n     just the most recently allocated.\n4. Threadsafe Heap Allocator\n   - A heap allocator which is additionally threadsafe and therefore provides an\n\t atomic reallocation function (as opposed to other allocators, which require\n\t you to alloc a new allocation, and then free the old one).\n\nI belive heap allocators are conceptually compatible with polymorphic allocators\nfor the most part. If the abstraction matches up, I plan to provide a polymorphic\nwrapper for these types, for use with the STL.\n\n## Performance and Compilation Time\n\nAllo does not use RTTI, exceptions, or virtual dispatch.\nTo improve compile times, it attempts to minimize use of the STL. Some headers\nthat are used are:\n\n- `\u003ctype_traits\u003e` for template magic\n- `\u003citerator\u003e` for stdlib iteration support (can optionally be disabled)\n- `\u003cutility\u003e` for `std::forward`, `std::move`, and `std::in_place_t`\n- `\u003cfunctional\u003e` for `std::ref`\n- `\u003cmemory\u003e` for `std::align` (only has effect on compile times in header-only mode)\n- `\u003ccstdint\u003e` and `\u003ccstddef\u003e` in public headers, as well as `\u003ccmath\u003e` in\n  header-only mode.\n\nAllo uses templates liberally, but avoids forcing user code to be templated.\n\n### Performance Benchmarks\n\nTBD. I personally made this library for the control it offers over memory, regardless\nof whether `heap_allocator_t` is slower than malloc. I'm leaving benchmarks until\nsomeone else uses this thing and wants that.\n\n## C++ Standard\n\nAllo supports C++17 and up. It was originally written for C++20 but was backported\nfor use on a game console. The C++20 elements are no longer present, but some\ndrop-in replacement features like requires-clauses are planned to be conditionally\navailable in the future.\n\n## Logging and formatting\n\nTBD. I would like to add fmtlib support for sure, but right now I just want dependencies\nto be light so I'm leaving it for later.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthe-argus%2Fallo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fthe-argus%2Fallo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fthe-argus%2Fallo/lists"}