On Tue, 8 Sep 2009 02:01:51 +0200 Ger Hobbelt <g...@hobbelt.com> wrote:
GH> Thanks for the summary; I'm following this as time allows.
GH>
GH> Critique: none so far. I applaud the move.
Thanks for looking at this!
GH> One nitpick: one typo glared at me in debugging.h @ #26:
GH>
GH> @section overview_debugging_config Configuing debugging support
GH>
GH> --> missing 'r':
Argh, bad Vim, bad. Why doesn't it check spelling in Doxygen sections
headers? I had to copy doxygenSpecialSectionDesc definition into my own
~/vim/syntax/doxygen.vim and modify it to contain "@Spell" to make this
work. I wonder if there is a better solution... Anyhow, thanks for noticing
this typo and there should be no more of them now that my Vim does keep an
eye on this.
GH> One bit of hmmmm: I'll have to see it more up close and personally in
GH> my own environment to see whether it simplifies the following (out of
GH> scope?) scenario:
No, it's not out of scope because it's quite common.
GH> using wxASSERTions in wx-related sections of my own
GH> application code, using either wxw-defined assertion backend code or
GH> custom defined alternatives. (I use the first, but only because I've
GH> been lazy/in a hurry when doing work which involved wxw so far.) When
GH> I got this right, simply setting the wxDEBUG_LEVEL define to the
GH> correct level will allow me to keep my 'in-app assertions' alive in
GH> any build, even when wxw itself was compiled with a different level.
Yes, and by default your assertions will remain enabled which, I believe,
is the right thing to do. The only difference is that while they show an
assert message box in debug builds, they do nothing, by default, in
release. But I recommend using wxSetAssertHandler() to change this and at
least log a message to your program log file about this or maybe throw an
exception which could then be caught and logged at the top level.
GH> Mind you, I'm not in favor of /always/ keeping assertions live, but
GH> wxw is a 'convenience' library rather than a lib where 'speed' is top
GH> priority (such as one might find for data processing libs). Only the
GH> latter type 'benefits' from stripping in-line run-time diagnostics
GH> such as assertions, to give it that extra bit of oompf in the final
GH> product, but this requires a different level of testing rigor as well,
GH> which is hard to accomplish for UIs. In a 'convenience' (UI) library,
GH> as long as the assertions don't eat up a major chunk of cpu time,
GH> they're perfectly fine to have around 24/7.
Unsurprisingly, I happen to think in the same way...
Regards,
VZ
