Now it is time to add my noise to the topic ... though I am not a
subversion developer.
Regarding redefining assert() and verify()
>> #define verify(x) do { assert(x); if (!(x)) abort(); } while(1)
> [...] (though I have a mild preference that "verify" be in all
> caps so it stands out as the macro it is).
assert() is an ANSI C macro defined in assert.h and should not be
redefined. If you want your own assert(), then define an SVN_ASSERT() or
whatever. You should also not define public ASSERT() and VERIFY macros
because these names are already used by Microsoft in their MFC class
library. You do not want to upset MFC userts that want to add subversion
to their projects, do you?
I understand from your discussion that abort() gives a nice core dump
where assert() would not. In Windows, it is usually the other way round,
as long as you run the debug version. abort() just aborts the
application without much information, assert() stops the debugger at the
error condition and allows you to examine your code and data.
You should also check the assert/ASSERT/_ASSERT support with Microsoft
compilers regarding debug/release versions of the binaries. As far as I
know, the Visual Studio license does not allow to ship the debug version
of the runtime libraries, and the debug version of your code might not
link to the release version of the libs. But maybe you find a way to use
assert with the RTL's relase version.
As one of the first posters in this thread, I know the "Writing Solid
Code" book by Steve Maguire, and I can only highly recommend it.
If you prefer assert over abort or vice versa is a question of code
philosophy. The idea of assert is to find bugs in the debug version of
you code during debugging. If you create a consistent set of rules when
to use assert to check for bugs, and when to check for erros at runtime
and abort, you can gain very much from assert during debugging, without
having the performance penalty of all the runtime checks.
Such rules could be:
- use assert() whenever possible to verify explicit and implicit
asumptions that the code implies.
- use assert() to check the correct usage of function/module interfaces.
If someone calls a function in an invalid way the assert should fail.
- never use assert() on conditions that might fail at runtime due to bad
input or lack of resources
- very important: During development, *always* run the debug version.
- very important: Run all new code under the debugger, try to execute as
much code paths as possible.
- Run all unit/regression/whatever tests with the debug version (as long
as you do not make performance tests).
- Use the release version of your code only for releases and for
speed/performance tests.
Following rules like these above, you should be able to catch nearly all
bugs that might lead to assertation failures before you build the first
release version. That means most these bugs find themselves
Trust your code! assert is a valuable debugging aid. Debug the debug
version, but release the release version! Do not let the customer (well,
end-user) debug your code.
asserts are a very big help during code development because it finds
many bugs in new code automatically. But once these obvious bugs have
been found during the debugging, they have fulfilled their purpose and
should not make the code slower in the release version.
When I started using asserts in this way I was as sceptical as some of
you. Today, the expierience with assert has changed my mind: I highly
trust the release version (which compiles with NDEBUG defined, meaning
the asserts disappear) when the debug version is full of asserts. I have
learned to trust the asserts. The bugs I was afraid for in the release
versions before using assert now find themselves...
I think I am not very good at telling you all this in english, maybe you
should get read the chapter about asserts in the above mentioned book to
get the idea. For me it has worked out very well, but, of course, you
need to make up your own mind about this.
Best Regards
Norbert Unterberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 12 00:13:56 2004