[Python-Dev] #ifdef __cplusplus?

[Matthieu Brucher]

Hi,

2009/1/2 Alexander Belopolsky <alexander.belopolsky at gmail.com>:
> First, by copying c++-sig, let me invite C++ experts to comment on
> this thread and the tracker issue:
>
> http://mail.python.org/pipermail/python-dev/2009-January/084685.html
> http://bugs.python.org/issue4805
>
> My patch highlights several issues:
>
> 1. (OP's issue.)  Do we need  #ifdef __cplusplus wrappers in .c files?

It seems that it is a reminiscence of old compilers, perhaps not even
supported anymore, thus it shouldn't be an issue anymore.

> 2. Should malloc() calls be prefixed with explicit type casts?

When I learnt C, I was always told to explicitely cast.

> 3. Should use of void* pointers be discouraged when typed pointers will work?

I think type checking is good in C.

> 4. Should exported symbols be always declared in headers or is it ok
> to just declare them as extern in .c files where they are used?

I agree with you, declaration should be put in headers, to prevent a
signature change for instance. One place is always better than several
places (you have to define them somewhere if you want to call them
without a warning). If we don't do this, we are back to the Fortran 77
days.
Besides, if those functions are not to be advertized, nothing prevents
them for inclusion inside "private" headers that are not included my
Python.h. This way, you can benefit from C checks, without the
advertizement (letting them in C files does not prevent their use,
putting them in headers prevents crashes).
With Visual Studio, you can say which function you want to export in
your library. This can be done with gcc as well, even if it is not the
default behavior.

> 5. Should the use of C++ keywords such as "new" or "class" be discouraged?

As CPython will not be ported to C++, I don't see the point of not
using "new" and "class" for variables names inside a function.

Matthieu
-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher