Tomas Härdin: > tis 2022-09-27 klockan 17:23 +0200 skrev Tomas Härdin: >> mån 2022-09-26 klockan 16:24 +0200 skrev Tomas Härdin: >>> mån 2022-09-26 klockan 14:25 +0200 skrev 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.) >>>> >>>> - Andreas >>> >>> So this means av_realloc_array_reuse()? Eh, it works. I will add a >>> function that also zeroes the newly allocated space, what should we >>> call that? av_realloc_array_reusez()? >>> av_realloc_array_reuse_zerofill()? >> >> Here's a draft patch that calls it av_reallocz_array_reuse(). Needs a >> minor version bump of course > > This makes me realize something: av_realloc_array_reuse() requires that > *nb_allocated == 0 initially but this isn't specified in the > documentation. Patch attached relaxes this. >
* @param[in,out] nb_allocated Pointer to the number of elements of the array * `*ptr`. `*nb_allocated` is updated to the new * number of allocated elements. If *ptr == NULL, then the number of elements of said array is (of course) zero, so *nb_allocated has to be set to that. (But if you think that this needs to be said explicitly, I can document it.) - 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".
