[FFmpeg-devel] Re: [RFC] C++

[Zhao Zhili via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]


> 在 2025年10月21日，上午1:50，Tomas Härdin via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 写道：
> 
> Hi
> 
> I'm writing this email to get a feel for how everyone feels about
> making more use of C++ in the codebase. I am only proposing using C++
> *internally*, and only where it makes sense. I am not suggesting a
> "move" to C++, merely using features already present in the compilers
> we target: gcc, clang and cl. The impedance mismatch should therefore
> be small, and any missing compiler features should be caught by FATE.
> 
> Currently C++ use is quite limited in this project, but I see no reason
> why this should be the case. doc/faq.texi makes mention of Linux'
> reasons for avoiding C++, but FFmpeg is not Linux. For us ABI stability
> and performance are the biggest issues. Stability can be ensured by
> sticking with C for the API and disabling exceptions (or marking
> relevant functions as noexcept). Performance may benefit in some cases.
> This would have to be tested. Again, the most performance critical
> parts can be kept as C (and asm).
> 
> My main motivation is to be able to use STL, which would simplify
> string handling and memory management, and give us access to its data
> structures. Manual memory management has its place, especially in lavc.
> In lavf less so. RAII would do wonders in de-gotofying error handling.
> Features like std::filesystem, std::chrono, std::thread etc abstract
> away many OS particularities. Thorough STL-ification would render parts
> of lavu obsolete. avstring.*, bprintf.* and tree.* come to mind. This
> would have security benefits. Another reason is stronger typing, which
> tends to reveal bugs.
> 
> I've targeted mxfdec.c as a proof-of-concept. See attached patch, which
> compiles and passes fate-mxf. It is partly inspired by our decklink
> binding. Particularly notable is the ability to resolve MXF structs
> into MXFMetadataSetType at compile time, as well as resolving strong
> references in a more type safe manner. This revealed an issue in
> mxf_parse_structural_metadata() where MXFStructuralComponent* was
> blindly cast to MXFTimecodeComponent*, which could cause code further
> down to interpret the latter as the former, which is a not so obvious
> bug that wouldn't be caught without this stronger typing.
> 
> I've not made use of STL in the attached patch because that requires
> linking with libstdc++, which I couldn't be arsed to do. One practical
> example where STL would come in handy is for my work on segmented
> indexes. Specifically std::map and std::lower_bound. Various tables in
> mxfdec.c could also be targets for turning into std::map or even
> std::unordered_map. A quick experiment with callgrind suggests
> mxf_read_header() might be speed up slightly with such a change.
> 
> Details like which version of C++ to use could be agreed on later if
> people feel this is a good idea. Personally I favor using the most
> recent version that our compiler suite supports. Lately I've been using
> C++20 with icx (Intel's compiler) which has been quite pleasant.

I noticed that the FFmpeg Twitter account posted about this discussion. I believe the discussion should remain within the mailing list.
Please keep in mind that C AND C++ developers make up the largest portion of our user base, although we choose to minimize the use of C++ inside FFmpeg itself.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org