I'm fairly certain that there is no way that Wei would abandon asserts anyway, but for the record, I believe that would be a horrible mistake. As mentioned by Christian, they are there to catch programming errors, not runtime errors. If you are following reasonable development processes you should be doing a ton of testing using the debug build and a debugger to stop you when it hits an assert. You won't crash inexplicably (most of the time anyway) and you get valuable, immediate information about what the program is doing wrong. The key thing that Christian failed to mention is that, in general, asserts are *automatically* removed in release mode; so, unless you tweak the makefiles to do something different, they will be compiled out for you. I have found that turning on asserts, but overloading how they are handled (via macro replacement), in release candidate builds so I get a diag output (syslog or stdout or whatever) on asserts that were missed because of differences between release and debug builds is invaluable. Most medium to large apps have lots of code that changes between release and debug, even if not intentionally, that you may trip an improper coding case only in release. Of course the asserts themselves are one such change, so it isn't perfect, but I have caught optimizer bugs this way and logic errors in seldom tested code paths (yes, use code coverage).
[/rant]
Asserts and exceptions serve incredibly valuable and very distinct purposes. Use the correct one for your purpose. There are lots of good reference material out there in books or on the net. Search for "coding by contract" and similar.
michael
At 02:15 PM 11/7/2003 +0100, you wrote:
Quoting Stephen torri ([EMAIL PROTECTED]): | I believe that asserts should be eliminated. They only cause the program | to 'Abort' and not give you any reason for why.
As other people have replied, ASSERTs in Crypto++ catches programming errors, indicating you've used the library incorrectly.
Such mistakes shold be caught during testing before releasing your code. Ideally, your code should be so well-tested that it would never abort in any given (practical) runtime-situation. If you've done this, and especially for embedded devices, you could possibly even remove ASSERTs in the release version.
| As a professor I know at Vanderbilt says where is stdout on a missle?
A good point that code should be properly tested. Apropos, many UNIX daemons close their stdout and stderr filehandles, since they should be performing their tasks silently and invisibly, or at least give reports using alternative channels (such as e.g. syslog).
-- Christian Stigen Larsen -- http://csl.sublevel3.org -- mob: +47 98 22 02 15
