This is a C library for an arena allocator, whose arenas are named Koliseo
.
It offers a basic API to perform initialisation, push (request arena memory), reset and free of a Koliseo
.
If you compile it without defining any special macros, you will get the basic functionality.
This is a basic usage example, initialising a Koliseo and then pushing an example pointer. You can build it by running:
gcc static/basic_example.c src/koliseo.c -o basic_example
For a more complete example, including Koliseo_Temp
usage, check out demo.c provided in static
folder.
typedef struct Example {
int val;
} Example;
#include "../src/koliseo.h"
int main(void)
{
//Init the arena
Koliseo* kls = kls_new(KLS_DEFAULT_SIZE);
//Use the arena (see demo for Koliseo_Temp usage)
Example* e = KLS_PUSH(kls, Example);
e->val = 42;
//Show contents to stdout
print_dbg_kls(kls);
//Free the arena
kls_free(kls);
return 0;
}
After including the koliseo.h
header:
- To initialise a default arena:
Koliseo* kls_new(size_t)
- To request memory for a specific type:
Type* KLS_PUSH(Koliseo* kls, Type)
- For C strings, you can use:
char* KLS_PUSH_STR(Koliseo* kls, char* cstring)
- Also, a couple unsafe utility macros (not recommended to use, for now):
char* KLS_STRDUP(Koliseo* kls, char* source, char* dest)
- To free the arena:
void kls_free(Koliseo* kls)
For more documentation on the available functions, see this section.
By default, extended functionalities are not included in the build, with each feature needing a preprocessor macro to be defined before including the library header. You can find hints on configuration here, or the list of macros here.
A ready-to-go index for every allocation you make.
- It uses a linked list and has some the memory overhead, due to hosting a couple static string buffers for the tags, so it may not be suited for all usecases.
- Offers extended API with tagging arguments, to type/name your references
- For now, two allocations backends can be chosen for the list, it can be stored:
- In an inner Koliseo (this puts an extra limit to the total number of single allocations)
- Using the global allocator (from malloc)
- Extra utility functions
- Help you estimate relative memory usage by some particular type of object. May prove useful in some scenarios.
Extra debug for core calls, may be too verbose for some applications.
Utility to memory-map a file (always the best idea, right?) to a C string, by providing the filepath.
- Also includes a minimal string-view API, in case you want to work on the file contents differently.
Any time LIST_T
is defined before including templates/list.h
, a basic linked-list implementation supporting Koliseo
allocation will be declared for the passed type.
- It can be done also after building a static object for the library.
The LIST_T
macro and the templates/list.h
should be repeatable without issues, allowing definition of more than one list interface.
This is implemented using some code-generating macros, which could rended build time slower if overused.
Defining the LIST_NAME
, LIST_PREFIX
and LIST_LINKAGE
can allow customisation for each list implementation:
LIST_NAME
: The name of the data type to be generated.- If not given, will expand to something like
list_int
for anint
.
- If not given, will expand to something like
LIST_PREFIX
: Prefix for generated functions.- If not given, will expand to something
LIST_NAME
+_
. (eg.list_int_
)
- If not given, will expand to something
LIST_LINKAGE
: Customize the linkage of the function.- If not given, will expand to
static inline
.
- If not given, will expand to
This is inspired by the dynamic array example by David Priver.
Include some experimental (NOT WELL TESTED. USE WITH CAUTION) functions.
In particular, enables the dreaded pop
operation and its functions.
To aid in building with extra features, see this section.
The preprocessor macros to enable them manually are:
- Region:
KOLISEO_HAS_REGION
- Debug:
KLS_DEBUG_CORE
- Gulp:
KOLISEO_HAS_GULP
- Experimental:
KOLISEO_HAS_EXPER
HTML docs are available at this Github Pages link.
You can also get the ready pdf version of the docs from the latest release.
If you have doxygen
you can generate the HTML yourself, or even the pdf if you have doxygen-latex
or equivalents.
To build the demo
binary, you need:
automake
andautoconf
to generate the neededMakefile
make
to build the binarygcc
orclang
, for buildingdemo
To bootstrap and use the ./anvil
tool to build all amboso-supported tags for demo
, you also need either:
bash >4.x, gawk
if you want to useamboso
rustc
if you want to useinvil
To prepare the files needed by autotools
, run:
aclocal
autoconf
automake --add-missing
./configure # Optionally, with --enable-debug or --host
make
You will get a ./configure
script, which you can use to enable debug mode or other features.
- Run
./configure --host x86-64-w64-mingw32
to setup theMakefile
appropriately for ax86_64-w64-mingw32
build. - Run
./configure --enable-debug
to setup theMakefile
appropriately and build with-DKLS_DEBUG_CORE
flag.- By default, enabling debug this way also adds
-DKLS_SETCONF_DEBUG
to the demo build. This preproc guard lets you really debug kls initialisation, by printing logs from insidekls_set_conf()
.
- By default, enabling debug this way also adds
- Run
./configure --enable-region
to setup theMakefile
appropriately and build with-DKOLISEO_HAS_REGION
flag. - Run
./configure --enable-gulp
to setup theMakefile
appropriately and build with-DKOLISEO_HAS_GULP
flag. - Run
./configure --enable-exper
to setup theMakefile
appropriately and build with-DKOLISEO_HAS_EXPER
flag.
To build both the libkoliseo.so
lib and demo
binary, run:
./configure
, which should generate theMakefile
. See Configuration section.make
, to build all target
ATM the code should build for:
x86_64-Linux
darwin-arm64
x86_64-w64-mingw32
to targetWindows
.- This build, while mostly identical to
Linux
/macOS
, is less tested.
- This build, while mostly identical to
Thanks to skeeto for showing me the original base implementation.
Thanks to Mako for the repo banner.
Thanks to Tsoding for its creative string view library (repo), which indeed does things so simply you mostly can't do anything different.
Thanks to David Priver for its dynamic array template example.
- Break up internal extensions to the core functionality
- Maybe move the guarded code into separate headers?
- Model
KLS_Temp_Conf
to still be included withoutRegion
feature - At the moment, the arena can't grown its own underlying buffer.
- Add backwards-compatible logic to enable growable arenas.
- Clean up the
Windows
part of the includes, to have minimal definitions fromwindows.h
.