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

[Romain Beauxis via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On Mon, Oct 20, 2025, 12:51 Tomas Härdin via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> 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 -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org