[Python-Dev] #ifdef __cplusplus?

Ulrich Eckhardt doomster at knuut.de
Fri Jan 2 10:49:57 CET 2009


On Friday 02 January 2009 06:17:24 Alexander Belopolsky wrote:
> Since that issue is closed, I have created
> http://bugs.python.org/issue4805 with a patch that restores C++
> compilability of the core and a few standard modules.

Looking at the patch, I see three main changes there:
1. Remove the extern "C" stanza from the .c files.
2. Add explicit casts where necessary for C++.
3. Include headers instead of locally declaring functions and adding some 
declarations to headers.

In particular the third part of above, I personally would definitely vote a 
+1. Since the first one is only necessary because things are declared 
sloppily, I'm also +1 on that one, i.e. #3 makes #1 possible.

As far as the second part is concerned, I personally wouldn't bother getting 
Python to compile with a C++ compiler. I'd also like to point out that a 
missing declaration of e.g. malloc(), and the ensuing implicit declaration 
as "int malloc(int)" will be hidden when there's an explicit cast, which is 
why e.g. the comp.lang.c FAQ is against it.

> Note that this discussion has deviated from OP's original question.
> While I argue that C++ compilability of source code is good thing, I
> agree with OP that wrapping non-header file code in extern "C" {} is
> bad practice.  For example, the only reason Objects/fileobject.c does
> not compile without extern "C" {} is because fclose is declared inside
> PyFile_FromString as follows:
>
>  PyObject *
>  PyFile_FromString(char *name, char *mode)
>  {
>  	extern int fclose(FILE *);
>  ..
>
> I would rather #include <stdio.h> at the top of the file instead.

This is change #3 above, and I'm all for it. I'm actually surprised that this 
code has actually escaped the peer review here.

Uli


More information about the Python-Dev mailing list