> Generally speaking, I think assert statements should normally not be > disabled at all, particularly not for release builds: if an assert > statement actually should fail, the program contains a very serious > logic error. Therefore it is not sensible to continue (and probably > crash shortly afterwards without printing a sensible error message). > OTOH, if continuation is possible or even sensible, it should not be an > assert statement but an if statement which then calls LOG(LOG_ERROR,...) > or LOG(LOG_WARNING,...).
Well, we disagree here, i guess :) For me assert() are there to debug the code, so should be turned off when doing releases. Which is incidentally what I do for Windows ^_- assert() are there to make sure your function is called correctly, to enforce arguments and such are ok - in release, you're expected to not have that behaviour. > I don't think this is a "WIN32" feature. Therefore I'm very reluctant to > add yet another #ifdef WIN32 block. Then don't readd it? > I fail to see why the compiler should emit a warning at all: the Ansi C > standard explicitly allows macro redefinition if (and only if) the two > definitions are identical (ignoring white space differences). Therefore > I suspect that the WIN32 build system does not define the macro NDEBUG > as the empty string. It is defined as empty string. Ryo _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
