On 2-mar-10, at 15:50, Norbert Nemec wrote:
bearophile wrote:
But generally public functions must test arguments in release mode
too, so I (and lot of other people) don't like to use asserts in
this situation. It's better to use an always present test followed
by a throw (so such test is not in the precondition).
For this statement, you should make a distinction between libraries
and applications.
Indeed, contracts are part of the interface, so a released library
should still allow to check for them.
Breach of a contract, however, is always a bug. In a correct
program, user interaction should never break either contracts or
assertions. If you trust your code enough to drop the assertions,
you can just as well drop the contracts.
The correct way to handled contracts for libraries would actually be
to store them as part of the library interface information. A
release-mode library would then contain neither assertions nor
contracts, but leave it to the compiler to add contract-checks for
calls to the library, when compiling an application in devel-mode.
well there are checks that I want to keep also in deployment, for
example if they check stuff that depends on user input.
Yes and if (!x) throw ...; is the correct way to handle this, but
sometime for stupid checks I would like to use the compactness of
assert, I already thought that having a aassert (always assert) would
be nice...
