Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: allow setting memory functions through callbacks (in addition to macros) #49

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

laurelkeys
Copy link
Contributor

Passing a function pointer to the library gives greater flexibility than through the #defines for FAST_OBJ_REALLOC/_FREE, as it's a choice that can be made (and changed) at runtime.

This PR adds a new (optional) fast_obj_set_memory_functions API for that, to set three new global variables in the FAST_OBJ_IMPLEMENTATION:

static fastObjRealloc memory_realloc = default_memory_realloc;
static fastObjFree memory_dealloc = default_memory_dealloc;
static void* memory_context = 0;

By default, these will fallback to calling FAST_OBJ_REALLOC and FAST_OBJ_FREE, so this is not a breaking change (I have still bumped the version to 1.4).

The two typedefs -- fastObjRealloc and fastObjFree -- take a void* context which allows for passing user data to the memory functions. Also, realloc takes both the new size and old size, to avoid the need of externally keeping track of allocation sizes.
I'd meant to do the same for the dealloc function (see https://nullprogram.com/blog/2023/12/17/), but ended up deciding against it as the majority of users will continue to use libc's free, thus leading to unnecessary strlen computations.


For context: the motivation behind this is that it will make it easier/cleaner to integrate fast_obj with arena allocators (where fastObjFree is usually a no-op). If this isn't deemed useful in the general case, feel free not to accept the PR 🙂

Albeit greater generality, removing this avoids unnecessary computations (notably strlen) in the common case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant