> 在 2025年10月21日，上午1:50，Tomas Härdin via ffmpeg-devel <[email protected]> > 写道： > > 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 -- [email protected] To unsubscribe send an email to [email protected]
