On Friday, 21 April 2017 at 12:57:25 UTC, Adam D. Ruppe wrote:
But I didn't realize your thing was a literal example from the
docs. Ugh, can't even trust that.
Which was a larger portion of why I was confused by it all than
otherwise.
Still, it's much easier to salvage if I knew how the memory being
returned was allocated or not, and if it could be de-allocated
after I was done with it, vs letting the gc manage it. The black
box vs white box approach.
Take a look at zlib.d's source
http://dpldocs.info/experimental-docs/source/std.zlib.d.html#L232
It isn't a long function, so if you take that you can
copy/paste the C parts to get you started with your own
function that manages the memory more efficiently to drop the
parts you don't care about.
I've worked directly with Zlib API in the past; However it was
namely to get it to work with AHK allowing me to instantly
compress text and see it's UUEncode64 output (which was fun) as
well as having multiple source references for better compression.
I think I'll just go with full memory compression and make a
quick simple filter to manage the large blocks of 0's to
something more manageable. That will reduce the memory allocation
issues.
