Tomorrow morning I'll put together CustomAllocatorEXT; I don't think I'll go with the structure layout but I can at least get the right idea put together and show it as working with the COM wrapper for now. As a sample of what an extension would look like, I took a function that was previous internal and marked "Do Not Use" and documented it a little better:
https://github.com/FNA-XNA/FAudio/commit/3f7fddc69570ffda25f7be1ddc87151c8ad...
-Ethan
On 10/21/18 14:54, Henri Verbeet wrote:
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.