On 22.10.2025 14:09, Gregor Riepl via ffmpeg-devel wrote:
>> 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?

C++ can be used as-is, since it can read all our headers just fine.
Using anything else needs extensive and constant porting work, that then 
will also make future iterations of internal APIs much harder if not 
impossible, forcing people who have zero experience with the other 
language to learn it, just to enhance the C side of things.

Plus, most of these fancy modern languages are not just a programming 
language, but they also want to play package-manager, which then forces 
all of its downstream users to babysit a ton of package version, which 
largely don't give a damn about stable APIs.
So we then need to constantly monitor all those dependencies for bugs 
and issues, and potentially a fix for one pulls in breaking API changes, 
which then need to be addressed and backported.

So stuff like Rust, and anything with similar insane package ecosystems, 
is a huge no from me.

Zig kinda seems interesting under those aspects, but seems a bit too 
immature still, and also kinda seems weird to me with its approach of 
taking over the entire build system, and not just being a compiler to 
integrate like any other.

> C++ has received a lot of criticism in being just as memory unsafe as C, 
> and I personally think that it adds an epic amount of complexity to 
> writing correct code. Although - that may or may not be the case 
> depending on where and how it's used in the code base.
> 
> I don't have any preference either way, but it seems to me that 
> investing effort to make the internals of FFmpeg safer and easier to use 
> would be better spent on a more modern and robust language than C++.
> 
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org