On 25/03/2011 08:04, Kagamin wrote:
So, there really is no good answer.
- Jonathan M Davis
So why do you need to differentiate between assert and enforce if you can't
choose, which of them should be used?
We can't really turn off both of them, and if we really want performance and no
checks, we would want to turn off both of them, so they should work in the same
way, shouldn't they?
I can't think of an occasion when I would want to have my uses of
enforce() stripped for a release build. Removing asserts once I am sure
that my code has no logic errors make sense, but removing the code that
validates user input and system integrity doesn't.
Performance is irrelevant if you are processing corrupted memory or
malformed input.
Before there we had enforce, I did tend to use assert for both cases as
I cobbled code together, then rewrite the validation parts as throws on
the second pass. When enforce appeared that 2 phase process got much
easier, and now I can choose the right one as I code, which increases
productivity.
Enforce does not replace assert, it compliments it, and very elegantly so.
<aside>
With regard to libraries, there is an overlap between what is input
validation and what is logic checking (a logic error in the code of
program a, results in bad input being sent to lib b). Here, assert is
the only choice as hitting an assert in a library (hopefully) exposes
logic errors in the program that uses the library, this is something
that you fix by reviewing your code, not by recovering at runtime and
trying again. This means that libraries (should) have 2 types of assert,
but I hesitate to suggest the creation of a synonym to help better
document the difference between them, as I find that the use of in{} and
out{} do a pretty good job of that already.
The only problems that I foresee are for libraries where the source is
not available (which I have not had an issue with yet) and libs that
wrap non-D code that does not use the same conventions. In these cases,
one will not always know if the -release flag (or equivalent) has been
used. If it has, then one may not find logic errors as one codes, if it
hasn't then one will find the errors, but will not be able to strip the
asserts when producing one's own release build.
</aside>
A...
