Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
I believe attached issue4846.diff should fix the problem, but I don't
have access to the affected platform (Windows?), so I did not test it.
I also wonder whether it would be more appropriate to redefine PyAPI_*
macros to declare API symbols with extern "C" when compiled under C++?
This seems to be a better approach than cluttering all header files with
#ifdef __cplusplus and worrying about the scope of extern "C" {}
wrappers.
Note that I considered whether _Py_ascii_whitespace declaration should
be done inside if !defined(HAVE_USABLE_WCHAR_T) .. directive and
concluded that it should not. My reasoning is as follows: _Py_ascii_whitespace
must be defined unconditionally in the .c file
because when python core is compiled, it is not known how an extension
module would define HAVE_USABLE_WCHAR_T. While it is not strictly
necessary to bring _Py_ascii_whitespace definition in an extension
module that has "USABLE_WCHAR_T", there is little to be gained from
hiding it because it is visible to the linker. Thus for the common uses
there is little practical difference between the two options but
unconditional declaration requires less code. On the other hand in the
context of issue4805, having unconditional declaration would allow
removing extern "C" wrappers from unicodeobject.c without loosing C++
compilability of python core.
----------
keywords: +patch
Added file: http://bugs.python.org/file12600/issue4846.diff
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4846>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
