[C++-sig] #ifdef __cplusplus?

[Alexander Belopolsky]

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?
2. Should malloc() calls be prefixed with explicit type casts?
3. Should use of void* pointers be discouraged when typed pointers will work?
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?
5. Should the use of C++ keywords such as "new" or "class" be discouraged?

On #1, I find it silly to have  #ifdef __cplusplus in the files that
cannot be compiled with C++ in the first place.  Even if the files are
fixed to compile with C++, I have arguments that  wrapping the entire
file in extern "C" is an overkill and hides design flaws.

On #4, Marc-Andre Lemburg commented on the tracker:
"""
Moving declarations into header files is not really in line with the way
Python developers use header files:

We usually only put code into header files that is meant for public use.

Buy putting declarations into the header files without additional
warning, you implicitly document them and make them usable in
non-interpreter code.
""" <http://bugs.python.org/msg78821>

I disagree.  Declaring functions in  .c files breaks dependency
analysis and may lead to subtle bugs.  AFAIK, Python's convention for
global functions that are not meant to be used outside of the
interpreter is the _Py prefix.  If an extra protection is deemed
necessary, non-public global symbols can be declared in separate
header files that are not included by Python.h.

On #3 and #5 arguments can be made that C++ compliant code is better
irrespective of C++.

#2 seems to be the most controversial, but explicit casts seem to be
the current norm and if perceived ugliness will discourage use of
mallocs in favor of higher level APIs, it is probably a good thing.

I believe restricting python core code to an intersection of c89 and
C++ will improve the overall self-consistency and portability of the
code and will allow python to be used in more systems, but since I
don't use C++ myself, I will only argue for changes such as #4 that
are independent of C++.

On Fri, Jan 2, 2009 at 12:31 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Sat, Jan 3, 2009 at 1:35 AM, Christian Heimes <lists at cheimes.de> wrote:
>> David Cournapeau schrieb:
>>> Can't those errors be found simply using appropriate warning flags in
>>> the C compiler ?  C has stopped being a subset of C++ a long time ago
>>
>> Python's C code still follow the ANSI C89 standard. The fact puts 'long
>> time ago' in a different perspective. :)
>
> In my mind, C++ is largely responsible for C not being a subset of
> C++, so the type of C used by the codebase is not that important in
> that context.
>
> David
>