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