I have the following situation.
I have a root project which contains a subproject.
This subproject is intended as a library, which you can either build stand-alone or it can be build alongside another project.
In the library I have to allocate memory at several locations.
I wish however, to be able to override this functionality.
For example, in the library I have a call to malloc(ptr).
And I wish to be able to replace these calls by a library consumer (in this case the rootproject).
The rootproject in this case should override/replace the calls in the library without the library being dependent on the rootproject.
For extra context I’m using this MACRO way because it is more performant than using function pointers for example, I am interested in high performance allocations in this case.
My question boils down to this:
What is the best practice for extending libraries like this?
I’ve found several related questions, but I am specifically interested in the best practice for these things; that it’s possible I am already aware of.
What I’ve so far to achieve what I want is the following.
- I’ve defined a header with macro’s replacing the allocations like so: HDR_MALLOC(ptr) malloc(ptr).
Every malloc(ptr) in the library now uses HDR_MALLOC(ptr) instead.
When the library is built standalone it simply uses this definition. - In the rootproject I’ve also defined a header with the macro HDR_MALLOC(ptr)
Now when building the library this works correctly, the rootproject correctly “overrides” the library’s HDR_MALLOC.
When rootproject uses the library, the library calls the rootproject’s implementation instead of it’s own.
1
In my experience, most libraries seem to reach for a macro-based system of configuration, with the ability for consumers to override by defining said macro themselves. The code pattern tends to be:
#if defined(LIB_CONFIG_HEADER)
#include LIB_CONFIG_HEADER
#else
// Include some reasonable defaults
#include <stdlib.h>
...
#endif
#if !defined(LIB_ALLOC)
#define LIB_ALLOC(_size) calloc(1u, _size)
#endif
This has the bonus flexibility of allowing otherwise invalid expressions like
#define LIB_ALLOC(_size) ...
#define LIB_ALLOC_T(_type) ((_type) *)LIB_ALLOC(sizeof(_type))
Since these are handled by the preprocessor, it also tends to be a useful pattern for embedded systems where a full or compliant standard library is not available.
Systems which require a more complex set of injectable behaviours tend to lean towards the function-pointer / vtable approach, which often also includes allocation methods. While this approach does involve some amount of indirection, in practice it is not a large amount of overhead.
There is also a third option involving weak linkage, but I would not recommend this.
Use function pointers, eg.
// lib.h
void libfoo(int one, double two, struct bar *three, void *(*alocfx)(size_t));
and, in the main project, call the library function
#include <stdlib.h>
#include "lib.h"
int main(void) {
libfoo(1, 3.14159, NULL, malloc);
}
4