>1) When writing Aspell I was under the impression that NDEBUG would not >be used except by those trying to squeeze the last 1-2% of performance out >of Aspell. If they chose to enable NDEBUG than it was at there own risk. >Defining NDEBUG for official binaries for Windows violates this assumption.
Yes, 1-2% is not worth the effort, but I assume not defining NDEBUG is a noop for msvc. >2) In some cases I use asserts to check non-obvious precondition of >functions. I do not want these checks disabled as they are not >expensive. These is especially important if the invalid input comes from >someone using the library incorrectly. If you wanna have the checks never disabled why do you gard them or use macros which doesn't work in default release mode? I would just introduce ASPELL_ASSERT which is agnostig to NDEBUG/_DEBUG >3) In some cases I am bad and use assert to check for invalid input in >several data files which, in general, the user should have no reason to >modify directly. I fully agree that these should be cleaned up. But >until they do, Aspell may behave mysteriously if it gets an invalid data >file and NDEBUG is not defined. use ASPELL_ASSERT until the cleanup >4) I also use NDEBUG in possib_err.hpp. Normally possib_err checks for >unhandled errors, with NDEBUG enabled it doesn't. I wrote thus with the >assumption in (1). Just use a other macro than NDEBUG (ASPELL_NDEBUG) which you define by yourself. PosibErr is really nice! Do you know the talk from Andrei Alexandrescu: http://www.nwcpp.org/Meetings/2006/05.html -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser _______________________________________________ Aspell-devel mailing list Aspell-devel@gnu.org http://lists.gnu.org/mailman/listinfo/aspell-devel
