On Sat, 20 Oct 2018 at 07:28, Ethan Lee flibitijibibo@flibitijibibo.com wrote:
In this case it would be something like "CustomAllocatorEXT", where all the construction entry points get a new overload like "FAudioCreateWithCustomAllocatorEXT", which is the same as the official FAudioCreate but with added parameters for function pointer types like FAudioCustomMallocEXT, and those would get stored in each context. The nice thing about everything being tied together in an extension is that I can document in big giant letters "DO NOT MIX ALLOCATORS" and avoid both the global variable safety issue as well as the malloc/free mismatch problems.
That's not that different from the example I gave. I called it faudio_create(), but I'm not set on a specific name. Note that the "struct faudio_create_info" scheme has API and ABI stability advantages though. If you ever need to add some extra optional parameters, you can pass those through the "next" pointer without breaking either the API or the ABI like this:
thread_info.type = FAUDIO_STRUCTURE_TYPE_THREAD_CREATE_INFO; thread_info.next = NULL;
thread_info.pfn_thread_create = pthread_create; thread_info.pfn_thread_join = pthread_join; ... create_info.next = &thread_info; ...
Even when you need to break the API, you can still keep the same ABI without having to do symbol versioning by assigning a different ID to FAUDIO_STRUCTURE_TYPE_CREATE_INFO.