[Robin Dunn] > I'm wondering if any other extension writers are having problems with > this code that was added to Python.h for 2.2? > > #ifndef Py_DEBUG > #ifndef NDEBUG > #define NDEBUG 1 > #endif > #endif > ... > In my case I end up with differences in the expected vs. actual > vtanles and so the wrong virtual methods are called followed shortly > by a core dump. > > If I have to I can make changes in my code or maybe in wxWindows to get > around this, but it was my understanding that NDEBUG should > always be set in the compile options and never in header files to avoid > this very problem. The Windows build has always defined NDEBUG in release builds via compile options. The Linux build never did (via compile option or anything else), so release builds on Linux (and presumably all other non-Windows boxes) contained code for assert() calls. The number of assert()s in the Python codebase has zoomed since I got commit privileges <wink>, so this was getting to be a significant expense. Guido added the #ifdef business to give the non-Windows platforms a release-build speed boost. I agree it's better done via command-line option; that's more work, though, and would require fiddling the build process for every non-Windows platform. fine-by-me-so-long-as-i-don't-have-to-do-it-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4