Andreas Rheinhardt: > Anton Khirnov: >> Quoting Andreas Rheinhardt (2022-07-14 14:51:07) >>> Anton Khirnov: >>>> Quoting Andreas Rheinhardt (2022-07-12 16:12:16) >>>>> Anton really dislikes the av_fast_* naming and instead wants this to be >>>>> called av_realloc_array_reuse(). I don't care either way. Any more >>>>> opinions on this (or on the patch itself)? >>>> >>>> If people dislike _reuse(), I am open to other reasonable suggestions. >>>> This 'fast' naming sucks because >>>> - it tells you nothing about how this function is "fast" >>>> - it is added at the beginning rather than the end, which is >>>> against standard namespacing conventions >>>> >>> >>> Isn't reusing the basic modus operandi for a reallocation function? So >>> your suggested name doesn't seem to fit either. >> >> Ordinary realloc just keeps the data, I wouldn't call that "reuse" since >> it will often be a copy. This "fast" realloc OTOH reuses the actual >> buffer, same as all the other "fast" mem.h functions. >> >> But feel free to suggest another naming pattern if you can think of one. >> > > I see two differences between this function and ordinary realloc: It > never shrinks the buffer and it overallocates. These two properties make > it more likely that these functions can avoid copies more often than > plain realloc (but in contrast to realloc, we can not grow the buffer in > case there is free space after it), but it is nevertheless the same as > realloc. > > But I don't really care that much about the name and will therefore use > your name as I can't come up with anything better. > (Of course, I am still open to alternative suggestions.) >
Here is a rebased branch that uses av_realloc_array_reuse: https://github.com/mkver/FFmpeg/commits/fast_realloc - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
