Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Mon, Jan 5, 2009 at 2:58 PM, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: .. > For completeness, all exported symbols in Python should have a _Py_ > prefix, even if they only get exported in certain debug builds. > I actually agree, but I felt that doing this as a part of this patch would make it even less likely to be accepted. There is another change that needs to be done to the alloc counts - namely changing the type from int to Py_ssize_t and %d to %zd in print formats. I will submit that as a separate issue. (See issue4850.) The only downside of having them is that a #ifdef __cplusplus instruction strongly suggests that a file is intended to be valid C++, which is currently not the case. > 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. So what is your position on the proposed patch? Is it worthwhile to track down the remaining symbols that may be affected by removal of extern "C" from .c files? What is your opinion on the original patch (c++-patch.diff) which restores C++ compilability but does not touch these declarations? I think using C++ as a lint variant from time to time is a good exercise to catch some corner issues as I hope this patch demonstrates. I don't think this should be a requirement on every submission, but once an effort is made to restore C++ compilability, such changes should be applied unless there are valid concerns against them. _______________________________________ 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
