[FFmpeg-devel] [PATCH] lavu: add av_bprintf and related.
Nicolas George
nicolas.george at normalesup.org
Sun Mar 11 17:20:16 CET 2012
Le duodi 22 ventôse, an CCXX, Stefano Sabatini a écrit :
> Nit+++: maybe you can remove some of these includes, not that I care much...
Removed stddef.
> Nit++: maybe asize -> a more descriptive name, such as available_size
> or automatic_size or a feasible abbreviation.
size_auto seems fine.
> You may add another example for max_size = 0:
>
> av_bprint_init(&b, 0, 0);
> bprint_pascal(&b, 25);
> printf("Long text in empty buffer: %zu/%u\n", strlen(b.str), b.len);
> av_bprint_finalize(&b, NULL);
Done, but finalize if not necessary.
> > +void av_bprint_init(AVBPrint *buf, unsigned size_init, unsigned size_max);
> Nit: init_size and max_size sound more correct to my
> non-native-English-speacker ears.
They are, but I want to see size_ as a kind of namespace prefix.
> Elaborating more on what I told the other time, using symbolic
> constants may help readability:
>
> av_bprint_init(&b, 0, -1) -> av_bprint_init(&b, 0, AV_BPRINT_UNLIMITED_SIZE)
> av_bprint_init(&b, 0, 1) -> av_bprint_init(&b, 0, AV_BPRINT_AUTOMATIC_SIZE)
> av_bprint_init(&b, 0, 0) -> av_bprint_init(&b, 0, AV_BPRINT_NULL_SIZE)
>
> so people won't have to check the docs.
>
> I agree that using a distinct parameter for the "buffering/appending
> mode" may increase API complexity too much, so I'm not sure that was a
> good idea.
I added them as convenience macros, but left the numeric values in the
example.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120311/cfe5fef6/attachment.asc>
More information about the ffmpeg-devel
mailing list