➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

作者 ncoghlan
收信人 eric.snow, ncoghlan, serhiy.storchaka, vstinner
日期 2017-03-23.12:48:00
SpamBayes Score -1.0
Marked as misclassified 是
Message-id <1490273280.72.0.566968293469.issue29881@psf.upfronthosting.co.za>
In-reply-to
内容
Passing var_decl was based on not knowing the answer to two questions:

* do we ever declare non-statics this way? (OTOH, if we do, this could be an opportunity to hide them behind read-only accessor functions)
* do we ever declare more specific types than PyObject * this way? (OTOH, if that's the uncommon case, requiring a cast to the more specific type probably wouldn't hurt)

As far as stack usage goes, all _Py_OnceVar instances should be in the data segment when using the linked list approach, so they shouldn't impact stack usage, and doing so retains the benefit of avoiding dynamic memory allocation just to track the static variable declarations. Since the macro is dereferencing the address of a static variable in the initialiser of another static variable, that shouldn't require any runtime stack space either. OTOH, I haven't actually ever tried compiling a macro like that, so it's entirely possible compilers won't like it.
历史
日期 用户 动作 参数
2017-03-23 12:48:00ncoghlan修改recipients: + ncoghlan, vstinner, eric.snow, serhiy.storchaka
2017-03-23 12:48:00ncoghlan修改messageid: <1490273280.72.0.566968293469.issue29881@psf.upfronthosting.co.za>
2017-03-23 12:48:00ncoghlan链接issue29881 messages
2017-03-23 12:48:00ncoghlan创建