Hi, I have very little time to work on FFmpeg lately but this thread caught my interest.
Nicolas George writes: > Anton Khirnov (12020-01-07): >> 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. > > [...] > > 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. I think this is really important, AVWriter allows the user to make use of whichever implementation of strings their application already uses and not have to deal with yet-another-string-type. > 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 relevant to this thread but: How would an application not using the traditional malloc() allocator work use FFmpeg at all if it didn't 'just work' by setting MALLOC_PREFIX? > [...] > > Etc. I hope you see my point and I do not need to add Java and PHP to > these examples. It's an issue that everyone is making their own string type, we do definitely not want to do this (one of the reasons I think this API is in the right direction). > 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. I guess the argument against this would be 'well, you can just copy it to whichever string implementation you need', which maybe isn't ideal but it 'works' currently. > 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. Important that we won't lose any functionality with this new API. > 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. Deferring error checks properly and centralising them means they can be better handled by a user. This is a good approach. > 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 don't think the complexity is a big issue here. > 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. For the most part I think the concept is good, and it definitely solves a problem which exists but the million dollar question is: Are strings a big enough issue at the moment that we should introduce a new API to fix them? Though I guess if someone is willing to implement a fix, then the answer to this doesn't even matter at all, and should always be 'yes'--you have my support for this set, at least. -- Josh _______________________________________________ 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".
