[FFmpeg-devel] AVWriter API

[Nicolas George]

Anton Khirnov (12020-01-07):
> Replying to this thread, since it contains the motivation.

Thanks.

> And most importantly - strings are simple. Every C programmer (worth the
> name) understands strings. But now you'd be forcing every API user to
> understand and remember this new API.

I'll reply to only that, because it contains the root of the problem.
No, strings are not simple. Strings only appear simple when you don't do
anything much with them. But as soon as you do, you need extra
complexity to implement them properly and efficiently.

And if you don't realize this is true, just observe that strings are so
simple that about every other library and most languages implement their
own version of strings, with the specific optimizations they think they
need.

Of course, FFmpeg does not do much with strings, and therefore can
pretend they are simple, but we are not talking about inside FFmpeg
here, we are talking about interacting with an application, an
application that probably does something with strings.

We will not play the game of reinventing yet another data structure for
strings, but let us not play the game of pretending the issue does not
exist: it only makes the problem more stinging.

Who wants a mallocated char pointer, really? Who things it is a good
idea for a string?

Not applications that use another allocator than malloc(), obviously.

Not Gtk+ applications, because they want a GString.

Not C++ application, because they want a boost string or something.

Not djb-style applications, because they want to use stralloc.

Not internationalized applications, because they want wchar_t.

Not Perl bindings, because they want to use a scalar value.

Etc. I hope you see my point and I do not need to add Java and PHP to
these examples.

By returning a mallocated char *, you are saying to the authors of these
applications "screw you, I don't care about your use case". If you don't
care about most applications' use cases, don't design public APIs.

This AVWriter API addresses all that. If the caller wants a mallocated
char *, they can get it, with almost no extra code. But if they want
something else, they can get it.

And even if it is used only for a mallocated char *, this code still
brings the benefit of factoring error checks. Error checks are "not to
be avoided", but they are not to be littered all over the code either:
they are often tricky, with the risk of leaks or double frees, and they
are almost never tested. Any change that centralizes them is good to
take, and this one of the things AVWriter does, centralize error checks.

As for the extra complexity. Yes, there is some. There is some
significant complexity in the implementation, of course. If it is
anybody's problem, it's mine.

There is a little complexity for the caller. Look at the code: very very
little complexity. Much less than what is required learning to use any
FFmpeg API anyway.

There is no complexity for the callee. If anything, using AVWriter makes
the callee code simpler.

I understand that you may be reluctant to embrace creative APIs, but
please try to go beyond that reluctance to see the actual benefits and
costs.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200112/a4bf9608/attachment.sig>