Benjamin Peterson <benja...@python.org> added the comment:
On Fri, Oct 26, 2018, at 03:18, STINNER Victor wrote:
>
> STINNER Victor <vstin...@redhat.com> added the comment:
>
> Benjamin:
> > Why do we need this Py_STATIC_INLINE macro? If you want to have one for
> > enabling always inline, that's fine with me, since it's compiler-specific.
>
> For about the name, there is already Py_LOCAL_INLINE which also uses
> "static inline", but has a very different usage: "Py_LOCAL can be used
> instead of static to get the fastest possible calling convention for
> functions that are local to a given module." So I chise
> "Py_STATIC_INLINE" name, it describes the basic implementation ("static
> inline TYPE").
I would like to see Py_LOCAL_INLINE removed, too, fwiw.
>
> Py_STATIC_INLINE() is designed to replace a preprocessor macro with a
> function, when you care that the code is "always inlined". (Maybe the
> name is not perfect ;-))
"always inline" is different from "static inline". So, it's not appropriate to
make a macro named the latter that has the former former.
>
> Honestly, I'm not sure that it really matters that the function is
> "always" inlined. The main issue is that "static" requires to duplicate
> the function in each file which uses the macro, when the function
> cannot/is not inlined.
>
>
> Previously, you asked me:
>
> > Does this slow down debug builds at all? It probably will not end will if
> > Py_INCREF is ever not inlined.
>
> That's why I wrote Py_STATIC_INLINE() to "force" inlining and PR 10094
> to enable inlining for Debug build on MSVC.
>
>
> > But the current Py_STATIC_INLINE macro seems to conflate linkage with
> > always-inline behavior.
>
> I'm not sure that I get it. Do you talk about "static" inside the macro?
> bpo-33407 modifies Py_DEPRECATED() to support Visual Stuido, but it
> requires to modify how the macro is used: it now must be used at the
> start, rather than at the end:
> https://github.com/python/cpython/pull/8980/files
>
> I chose to put "static" and "inline" in the same macro. We already have
> many other similar macros like PyAPI_FUNC(TYPE) and Py_LOCAL(TYPE). I
> would like to have a common way to "declare a function behaving as a
> macro".
We don't want functions that behave like macros... otherwise, we would be
writing macros. If we want a function to always be inlined, we should
explicitly request that from the compiler.
>
>
> Please see also the discussion on the PR itself, Neil discuss what's the
> best way to declare an inline function:
> https://github.com/python/cpython/pull/10079#issuecomment-433230587
>
> By the way, was it you who required "static inline" support in PEP 7? :-)
Yes, which is why we shouldn't need a macro to write it.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35059>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
