On 2009-01-05 19:55, Alexander Belopolsky wrote:
> The allocs counters (tuple_zero_allocs, fast_tuple_allocs,
> quick_int_allocs, quick_neg_int_allocs) present a case where it is
> really hard to justify a change that is only motivated by C++
> compilability.   Note that currently they are not getting extern "C"
> at the point of definition (Objects/tupleobject.c and
> Objects/intobject.c) but do at the point of declaration
> (Objects/object.c).  Moving them to a header file would require
> renaming with a _Py_ prefix.  Affected applications are really
> esoteric: MS C++ compilation with -DCOUNT_ALLOCS.

For completeness, all exported symbols in Python should have a _Py_
prefix, even if they only get exported in certain debug builds.

> I find it hard to get motivated to do a more thorough review of the
> code searching for affected non-function symbols.  My original
> motivation was just the curiosity as to why extern "C"  were added to
> .c files.  I got my questions answered and I believe these
> declarations serve no valid purpose, particularly inside the files
> that no longer valid C++.

Like I mentioned earlier on: those declarations did serve a purpose
for early MS VC++ versions (at least AFAIR). It may well be the case
that they are no longer needed nowadays, but then they don't hurt
much either.

Given that you can build Python as library on Unix and as DLL on
Windows, there doesn't appear to be any need to actually be able
to build Python itself using a C++ compiler. Simply using the
header files and linking against those libraries should do the
trick in most cases.