ons 2025-10-22 klockan 14:09 +0200 skrev Gregor Riepl via ffmpeg-devel: > > 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. > > Just for the sake of the argument: Wouldn't it be better to opt for > an even safer language than C++, like Rust?
There was a discussion about Rust a while back. I'm not really against it, but the impedance mismatch is much greater. Plus there's the need for an entirely different set of compilers. Most of our users know C++ already. That said, gccrs is making progress so perhaps at some point this might happen. C++ is still an improvement over the present state of things. Plus, Katamari-C++ is likely to grow the same kind of features Rust has anyway. I've continued to hack at mxfdec.cpp and I'm now seeing substantial performance improvements thanks to using STL. 182% faster mxf_read_header for a 10,000 second file generated by mxfenc.c. This is likely to shoot up even more as I rework the MXFIndexTableSegment code. Greater still would be the effect of lazy reading of partitions, which is my overall goal. I'll probably push something to forgejo once it's firmed up a bit. Especially for Baptiste to take a look at. I feel I should reiterate the point that whatever we choose to do we should keep the C API, because C's ABI is stable. C++'s isn't, and based on what Rémi is saying Rust's isn't either. /Tomas _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
