From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS
Date: Tue, 31 Jan 2023 22:02:05 +0100
Message-ID: <GV1P250MB0737BA8CA5A2D2ECA97452698FD09@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <Y9lDFNw1bKH/e/Nn@phare.normalesup.org>
Nicolas George:
> Nicolas George (12023-01-31):
>>> * it prevents filterlink internals from being visible in a
>>> public header, where they have no business being
>>> * it is a step towards hiding more of lavfi internals from public
>>> headers
>>> * the same pattern is already and ever more widely used in the other
>
> Note to the TC who will decide: I do not oppose the efforts mentioned in
> these two points (that are actually the same points twice), I only
> oppose this particular solution because of this drawback:
>
>> * It requires the developers to remember which field is public and which
>> field is private, which is not something relevant here (is is relevant
>> elsewhere).
>
> Without looking very far, I can think of several different ways of
> hiding the internal fields better without requiring changes to the
> implementation. I would not oppose such a change.
>
Details please. I can only think of the following:
a) Allow the use of -fms-extensions. This allows structs with tags and
typedefs thereof to be used as unnamed struct members with the members
of the unnamed structure being treated as members of the enclosing
structure. One could then use a pointer to the big internal structure
internally and one does not need to remember whether a field is internal
or not. There is still a problem, though: One needs to cast from
AVFilterContext.(inputs|outputs). This should be done via dedicated
inlined getters, but this is a bit more typing. E.g.
"input_from_ctx(ctx, i)" instead of "ctx->inputs[i]". Of course, it
might also be shorter if someone has a short name.
GCC, Clang, MSVC and the IIRC the intel compilers support this.
b) Add a big #define AVFILTERLINK in avfilter.h that expands to the
public part of AVFilterLink and change the declaration of AVFilterLink
to "struct AVFilterLink { AVFILTERLINK };" and use declare the internal
struct via
"struct FilterLinkInternal {
AVFILTERLINK
/* actual internal fields */
};"
This has the downside of actually being an aliasing violation and of
adding considerable ugliness to avfilter.h, in particular during
deprecations (like with FF_API_OLD_CHANNEL_LAYOUT -- you can't check via
#if in the implementation of a macro). I also don't know whether it
plays nicely with tools that deal with source code annotations.
c) Wrap the internal part in an #ifdef HAVE_AV_CONFIG_H, optionally
using #if defined(HAVE_AV_CONFIG_H) && defined(BUILDING_avfilter).
d) Same as c), but strip this stuff from installed headers.
I consider b)-d) as inferior to a), which I consider superior to Anton's
proposal, but the big drawback is its reliance on a compiler extension.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2023-01-31 21:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 12:29 Anton Khirnov
2023-01-30 12:32 ` Paul B Mahol
2023-01-30 12:40 ` Nicolas George
2023-01-31 13:50 ` Anton Khirnov
2023-01-31 14:03 ` Nicolas George
2023-01-31 14:14 ` Paul B Mahol
2023-01-31 14:32 ` Nicolas George
2023-01-31 14:50 ` Paul B Mahol
2023-01-31 14:18 ` Anton Khirnov
2023-01-31 14:31 ` Nicolas George
2023-01-31 15:24 ` Anton Khirnov
2023-01-31 16:13 ` Nicolas George
2023-01-31 16:34 ` Nicolas George
2023-01-31 21:02 ` Andreas Rheinhardt [this message]
2023-01-31 21:16 ` Nicolas George
2023-02-01 0:31 ` Andreas Rheinhardt
2023-02-01 7:47 ` Nicolas George
2023-02-01 13:48 ` Andreas Rheinhardt
2023-02-03 14:45 ` Nicolas George
2023-02-04 11:09 ` Uoti Urpala
2023-02-04 15:27 ` Andreas Rheinhardt
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=GV1P250MB0737BA8CA5A2D2ECA97452698FD09@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM \
--to=andreas.rheinhardt@outlook.com \
--cc=ffmpeg-devel@ffmpeg.org \
/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