[iostreams] Custom allocator support for compression filters
Hello everyone, I'm currently looking into custom allocators with the boost::iostreams::gzip_compressor and now need some help understanding why the code is the way it is. My problem is that I need to control how zlib internally de-/allocates memory. It seems to have support for using custom de-/allocation functions. And iostreams seems to have used it some time ago. However, passing the custom allocator to zlib has been disabled in this commit: https://github.com/boostorg/iostreams/commit/95baf782098f0dee00cc7ca6f62b9b1... Does anyone happen to know what has been non-conforming and why it was disabled? I could not find any information about that in the code, on the mailing lists, or anywhere else in the internet. I'm tempted to submit a patch that enables it, but for that I need to understand the reasons behind that deliberate decision. Any hint is welcome. Thank you very much. Daniel B?hme
Daniel Boehme wrote:
Hello everyone,
I'm currently looking into custom allocators with the boost::iostreams::gzip_compressor and now need some help understanding why the code is the way it is.
My problem is that I need to control how zlib internally de-/allocates memory.
It seems to have support for using custom de-/allocation functions. And iostreams seems to have used it some time ago. However, passing the custom allocator to zlib has been disabled in this commit: https://github.com/boostorg/iostreams/commit/95baf782098f0dee00cc7ca6 f62b9b105ca6573f
Does anyone happen to know what has been non-conforming and why it was disabled? I could not find any information about that in the code, on the mailing lists, or anywhere else in the internet.
I'm tempted to submit a patch that enables it, but for that I need to understand the reasons behind that deliberate decision.
Any hint is welcome.
My _guess_ is that the non-conformity refers to the fact that pointers to C functions (extern "C") and pointers to C++ functions are not guaranteed to be compatible. Since zlib accepts pointers to C functions, and the allocator wrapper class defines C++ functions, assigning one to the other is not guaranteed to work. However... in practice, this works essentially everywhere. EDG-based compilers used to reject this (many years ago), but I don't know whether this remains a problem today on any platform we support.
participants (2)
-
Daniel Boehme
-
Peter Dimov