extern "C" { ... } in Include/cpython/*.h
(Apologies. Not sure where to ask this, and I'm not much of a C++ programmer. Maybe I should have just added a comment to the still-open issue.) I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's not clear to me that the latter should be #include'd directly from anywhere other than Include/frameobject.h. If that's the case, does the extern "C" stuff still need to be replicated in the lower level file? Won't the scope of the extern "C" block in Include/frameobject.h be active at the lower level? Whatever the correct answer is, I suspect the same constraints should apply to all Include/cpython/*.h files. Skip
On 2020-01-27 21:42, Skip Montanaro wrote:
(Apologies. Not sure where to ask this, and I'm not much of a C++ programmer. Maybe I should have just added a comment to the still-open issue.)
I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's not clear to me that the latter should be #include'd directly from anywhere other than Include/frameobject.h. If that's the case, does the extern "C" stuff still need to be replicated in the lower level file? Won't the scope of the extern "C" block in Include/frameobject.h be active at the lower level?
Whatever the correct answer is, I suspect the same constraints should apply to all Include/cpython/*.h files.
You're correct: - The #ifndef/#error make a clear point that a include/cpython/*.h file is only to be included as part of its include/*.h - The inner extern "C" block overrides the outer one. If they're the same, it's useless. But I'd call it a minor issue – a style issue, even. Probably not worth worrying about.
On Tue, 28 Jan 2020 at 20:43, Petr Viktorin <encukou@gmail.com> wrote:
On 2020-01-27 21:42, Skip Montanaro wrote:
I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's not clear to me that the latter should be #include'd directly from anywhere other than Include/frameobject.h. If that's the case, does the extern "C" stuff still need to be replicated in the lower level file? Won't the scope of the extern "C" block in Include/frameobject.h be active at the lower level?
Whatever the correct answer is, I suspect the same constraints should apply to all Include/cpython/*.h files.
You're correct: - The #ifndef/#error make a clear point that a include/cpython/*.h file is only to be included as part of its include/*.h - The inner extern "C" block overrides the outer one. If they're the same, it's useless.
I hadn't thought about this before (and presumably Victor hadn't either when he did the initial set of header splits), but yeah, I think you're right - the inner C-style linking declarations are redundant, given the macro definitions checks that ensure these files are always going to be included inside the outer C-style linking declarations.
But I'd call it a minor issue – a style issue, even. Probably not worth worrying about.
A quick code search says there are only 18 header files affected by this at the moment - if we were to clean those up, then any future file splits would presumably copy that improved style, rather than perpetuating the redundancy. So call it a +0 from me for tidying them up. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Nick Coghlan -
Petr Viktorin -
Skip Montanaro