[crossfire] Re: [Crossfire-cvs] CVS commit: client

[Nicolas Weeger]

>
     
      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