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.

/Tomas