Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: ffmpeg-devel@ffmpeg.org
Cc: "Rémi Denis-Courmont" <remi@remlab.net>
Subject: [FFmpeg-devel] Re: [RFC] C++
Date: Wed, 22 Oct 2025 20:08:18 +0300
Message-ID: <12317178.1AZP7vizG9@basile.remlab.net> (raw)
In-Reply-To: <e2c76a7b-2e3e-4838-84c7-e4eed4b6aac6@gmail.com>

Le keskiviikkona 22. lokakuuta 2025, 15.09.32 Itä-Euroopan kesäaika Gregor 
Riepl via ffmpeg-devel a écrit :
> > 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?

Yes. If the goal is to use better abstraction, notably for data structures and 
memory handling, than are possible with C, then Rust provides zero-cost 
abstractions. In C++, you can't do that; for instance, your virtual methods 
may or may not be specialised, and you have no control over it. Also C++ 
provides a lot of abstractions that are nowadays widely considered just *bad*, 
even by C++ advocates, such as multiple inheritance.

Rust also doesn't need its own runtime library, so it would be essentially 
transparent for (binary) downstreams, whether statically or dynamically 
linked. And it's actually easy for experienced C programmers to learn (been 
there, done that).

The static memory safety features are just icing on the cake.

The big difficult is integrating dependency tracking from rustc, compilation 
(rustc or cargo) and linking into an existing build system. But that's a one-
time cost for one motivated person to deal with. Sure, C++ would be much 
easier with respect to that one specific aspect, but so what?

> 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.

+1

-- 
德尼-库尔蒙‧雷米
Tapiolan uusi kaupunki, Uudenmaan entinen Suomen tasavalta



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

  parent reply	other threads:[~2025-10-22 17:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 17:50 [FFmpeg-devel] " Tomas Härdin via ffmpeg-devel
2025-10-20 21:34 ` [FFmpeg-devel] " Neal Gompa via ffmpeg-devel
2025-10-21  2:24 ` Lynne via ffmpeg-devel
2025-10-22  8:57   ` Tomas Härdin via ffmpeg-devel
2025-10-22 10:46   ` Tomas Härdin via ffmpeg-devel
2025-10-21 18:41 ` Niklas Haas via ffmpeg-devel
2025-10-22  3:15 ` Romain Beauxis via ffmpeg-devel
2025-10-22  4:19   ` InnocentZero via ffmpeg-devel
2025-10-22  8:24   ` Nicolas George via ffmpeg-devel
2025-10-22 10:53   ` Tomas Härdin via ffmpeg-devel
2025-10-22 12:09 ` Gregor Riepl via ffmpeg-devel
2025-10-22 12:42   ` Michael Niedermayer via ffmpeg-devel
2025-10-22 13:07   ` Timo Rothenpieler via ffmpeg-devel
2025-10-22 17:07     ` Rémi Denis-Courmont via ffmpeg-devel
2025-10-22 18:12       ` Timo Rothenpieler via ffmpeg-devel
2025-10-22 18:50         ` Rémi Denis-Courmont via ffmpeg-devel
2025-10-22 17:08   ` Rémi Denis-Courmont via ffmpeg-devel [this message]
2025-10-23 21:45   ` Tomas Härdin via ffmpeg-devel
2025-10-22 13:05 ` Michael Niedermayer via ffmpeg-devel
2025-10-23 21:49   ` Tomas Härdin via ffmpeg-devel
2025-10-23 22:24     ` Michael Niedermayer via ffmpeg-devel
2025-10-22 14:03 ` Leo Izen via ffmpeg-devel
2025-10-21 14:47 Zhao Zhili via ffmpeg-devel
2025-10-21 14:58 ` Nicolas George via ffmpeg-devel
2025-10-21 15:31   ` Zhao Zhili via ffmpeg-devel
2025-10-22  1:34     ` Michael Niedermayer via ffmpeg-devel
2025-10-22  8:11     ` Nicolas George via ffmpeg-devel
2025-10-22  9:15       ` Zhao Zhili via ffmpeg-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12317178.1AZP7vizG9@basile.remlab.net \
    --to=ffmpeg-devel@ffmpeg.org \
    --cc=remi@remlab.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git