Message212346
| Author |
kristjan.jonsson |
| Recipients |
Arfrever, benjamin.peterson, brett.cannon, georg.brandl, kristjan.jonsson, larry, loewis, pitrou, rhettinger, serhiy.storchaka, skrah, taleinat, vstinner |
| Date |
2014年02月27日.09:56:22 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1393494982.99.0.967313431565.issue20440@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Are you referring to the Py_LOCAL_INLINE macro?
I see that we have no Py_INLINE. Py_LOCAL_INLINE includes the "static" qualifier, and in fact, if there is no "USE_INLINE" defined, then all that it does is to add "static".
Would having a "Py_INLINE(type)" macro, that is the same, but without the static (except when USE_INLINE is false) make a difference? It would be a bit odd to have Py_LOCAL_INLINE() functions defined in the headers.
I'm not sure that there is any practical difference between "static inline" and "inline". But there is a difference between "static" and "inline".
It would be great if we could start writing stuff like the Py_INCREF() and Py_DECREF() as functions rather than macros, but for this to happen we must be able to trust that they are really inlined. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年02月27日 09:56:23 | kristjan.jonsson | set | recipients:
+ kristjan.jonsson, loewis, brett.cannon, georg.brandl, rhettinger, pitrou, vstinner, taleinat, larry, benjamin.peterson, Arfrever, skrah, serhiy.storchaka |
| 2014年02月27日 09:56:22 | kristjan.jonsson | set | messageid: <1393494982.99.0.967313431565.issue20440@psf.upfronthosting.co.za> |
| 2014年02月27日 09:56:22 | kristjan.jonsson | link | issue20440 messages |
| 2014年02月27日 09:56:22 | kristjan.jonsson | create |
|