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

[Timo Rothenpieler via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2468 bytes --]

On 22.10.2025 19:07, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le keskiviikkona 22. lokakuuta 2025, 16.07.36 Itä-Euroopan kesäaika Timo
> Rothenpieler via ffmpeg-devel a écrit :
>> C++ can be used as-is, since it can read all our headers just fine.
> 
> FFmpeg public headers are C++-compatible and, frankly as a C developer, I find
> that annoying. Not sure about Zig, but Rust does not care about your C headers
> and won't require C programmers to muck with their header files to appease
> rustc.
> 
> Or more accurately, it gives you the choice to use or not to use bindgen to
> parse the C headers. And frankly, you are more often than not better off not
> using it.
> 
>> 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.
> 
> C++ sucks just as badly as Rust to make stable APIs/ABIs. In the end, you end
> up having to expose a C interface, whether you're using C, C++, Zig, Rust or
> anything else. And you'll have to do that forever, since C is the lingua
> franca of system-level programming interfaces.
> 
>> 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.
> 
> FUD much? How exactly do any other language relieve you from the problem of
> tracking bugs in dependencies?

They allow a distributor to do it centrally, and don't burden it onto 
every single developer.

> Cargo gives you the *choice* of pinning or not pinning the versions through
> the lock. FFmpeg should *probably* not pin anything and just specify minimum
> version requirements. And it'll be the exact same dependency hell that we
> already have (or don't have - that's subjective) with C. Nothing to see here.

Given that API stability is far from a given in that world, not pinning 
anything does not sound like a good idea.
I'd rather just not enter that dependency hell at all.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org