unicode objects and C++
I struck a bit of a snag with the Unicode support when trying to use the most recent update in a C++ source file. The problem turned out to be that unicodeobject.h did a #include "wchar.h", but did it while an 'extern "C"' block was open. This upset the MSVC6 wchar.h, as it has special C++ support. Attached below is a patch I made to unicodeobject.h that solved my problem and allowed my compilations to succeed. Theoretically the same problem could exist for wctype.h, and probably lots of other headers, but this is the immediate problem :-) An alternative patch would be to #include "whcar.h" in PC\config.h outside of any 'extern "C"' blocks - wchar.h on Windows has guards that allows for multiple includes, so the unicodeobject.h include of that file will succeed, but not have the side-effect it has now. Im not sure what the preferred solution is - quite possibly the PC\config.h change, but Ive include the unicodeobject.h patch anyway :-) Mark. *** unicodeobject.h 2000/03/13 23:22:24 2.2 --- unicodeobject.h 2000/03/14 01:06:57 *************** *** 85,91 **** --- 85,101 ---- #endif #ifdef HAVE_WCHAR_H + + #ifdef __cplusplus + } /* Close the 'extern "C"' before bringing in system headers */ + #endif + # include "wchar.h" + + #ifdef __cplusplus + extern "C" { + #endif + #endif #ifdef HAVE_USABLE_WCHAR_T
Mark Hammond wrote:
I struck a bit of a snag with the Unicode support when trying to use the most recent update in a C++ source file.
The problem turned out to be that unicodeobject.h did a #include "wchar.h", but did it while an 'extern "C"' block was open. This upset the MSVC6 wchar.h, as it has special C++ support.
Thanks for reporting this.
Attached below is a patch I made to unicodeobject.h that solved my problem and allowed my compilations to succeed. Theoretically the same problem could exist for wctype.h, and probably lots of other headers, but this is the immediate problem :-)
An alternative patch would be to #include "whcar.h" in PC\config.h outside of any 'extern "C"' blocks - wchar.h on Windows has guards that allows for multiple includes, so the unicodeobject.h include of that file will succeed, but not have the side-effect it has now.
Im not sure what the preferred solution is - quite possibly the PC\config.h change, but Ive include the unicodeobject.h patch anyway :-)
Mark.
*** unicodeobject.h 2000/03/13 23:22:24 2.2 --- unicodeobject.h 2000/03/14 01:06:57 *************** *** 85,91 **** --- 85,101 ---- #endif
#ifdef HAVE_WCHAR_H + + #ifdef __cplusplus + } /* Close the 'extern "C"' before bringing in system headers */ + #endif + # include "wchar.h" + + #ifdef __cplusplus + extern "C" { + #endif + #endif
#ifdef HAVE_USABLE_WCHAR_T
I've included this patch (should solve the problem for all inlcuded system header files, since it wraps only the Unicode APIs in extern "C"): --- /home/lemburg/clients/cnri/CVS-Python/Include/unicodeobject.h Fri Mar 10 23:33:05 2000 +++ unicodeobject.h Tue Mar 14 10:38:08 2000 @@ -1,10 +1,7 @@ #ifndef Py_UNICODEOBJECT_H #define Py_UNICODEOBJECT_H -#ifdef __cplusplus -extern "C" { -#endif /* Unicode implementation based on original code by Fredrik Lundh, modified by Marc-Andre Lemburg (mal@lemburg.com) according to the @@ -167,10 +165,14 @@ typedef unsigned short Py_UNICODE; #define Py_UNICODE_MATCH(string, offset, substring)\ (!memcmp((string)->str + (offset), (substring)->str,\ (substring)->length*sizeof(Py_UNICODE))) +#ifdef __cplusplus +extern "C" { +#endif + /* --- Unicode Type ------------------------------------------------------- */ typedef struct { PyObject_HEAD int length; /* Length of raw Unicode data in buffer */ I'll post a complete Unicode update patch by the end of the week for inclusion in CVS. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (2)
-
M.-A. Lemburg
-
Mark Hammond