On Mon, Oct 20, 2025, 12:51 Tomas Härdin via ffmpeg-devel < [email protected]> wrote:
> 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. I understand the benefit of using higher order APIs borrowed from C++ but, to fully make your case I think it'd be important to know: is it possible to use STL and avoid linking with libstc++? 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. > > /Tomas > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
