Marc-Andre Lemburg <m...@egenix.com> added the comment: 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. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4805> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com