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

[Neal Gompa via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On Mon, Oct 20, 2025 at 1:51 PM 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. 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 think it'd be great if this was done. Actually, RPM made a similar
move for RPM 6.0[1] for precisely the same reason.

From my point of view, it would make it easier for me to understand
the code as I'm more of a C++ guy than a C guy. And I feel like
there's a longer-term benefit to simplify code by not needing to
recreate data structures that are perfectly usable from the STL.

That said, from a C++ standard perspective, C++20 is a great place to
start from. RPM, KDE, and other major Free Software projects using C++
have moved to it and liked the improvements to C/C++ it offers.

[1]: https://rpm.org/releases/6.0.0



-- 
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org