Re: [lmi] NDEBUG

[Vadim Zeitlin]

On Thu, 23 Oct 2014 12:39:54 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-19 19:25Z, Vadim Zeitlin wrote:
...
GC> >  I've just realized that this is actually a potential problem.
...
GC> Okay. Maybe I'm missing something, but I don't see this as a problem.

 Then it isn't one. As I wrote above, I was afraid it could be a problem,
just because this behaviour is somewhat unintuitive (although IMHO it does
make sense once you think about it) and also because it's a change since
wxWidgets 2.8. But if you understand and accept it, there is, once again,
no problem.

GC> AFAIK, the typical dichotomy is:
GC>  - "release" builds:   optimized;   no debug symbols; NDEBUG defined
GC>  - "debug" builds: not optimized; full debug symbols; NDEBUG not defined
GC> and the idea is that developers work with the latter, but ship the former.
GC> Instead, I normally build only one way--with optimization and debug
GC> symbols--and don't define NDEBUG, for these reasons:

 FWIW I understand and agree with these reasons, but there are other
reasons to distinguish between debug/release builds as well and wxWidgets
3.0 debug facilities try to be a compromise between these two points of
view. I.e. what motivated these changes in the first place was the desire
to move closer to your position, as pre-3.0 wxWidgets was firmly in "debug
or release" camp.

GC> Debug symbols don't slow the program down. They make binaries larger

 This is unfortunately one thing in which MinGW is lacking. Both MSVC
(since always) and g++ under Unix platforms (since a few years already) can
extract debug symbols to separate files (.pdb in the former case, .debug in
the latter one) which completely negates any disadvantages of generating
the debug symbols. But, again, to the best of my knowledge, MinGW can't do
this yet.

 FWIW I do feel pretty strongly about debug symbols and IMO they must
always be generated. Whatever the merits of the programmer, program can
still crash at the end user's machine, sometimes for reasons outside of the
programmer's control (e.g. loading some broken third party DLLs -- what
about crashing only when printing on some particular model of printer, just
because it turned out that its driver corrupted memory?), and without debug
symbols there is no hope of identifying the problem.

GC> You mentioned that wxLogDebug(), wxASSERT(), wxFAIL, wxCHECK, etc. are
GC> not really meant for end users. Here, I would prefer to leave well
GC> enough alone: in practice, they never see this stuff; and if they ever
GC> do, I'd like them to tell us. These facilities have on occasion helped
GC> our testing. We certainly don't want to test two different builds of
GC> the same wx release.
GC> 
GC> Is there any other reason to change anything?

 If you're unafraid of your users seeing a scary message box if something
does go wrong, no. The idea is that, as these message boxes are not meant
to be shown to the users, most developers prefer to turn them off to ensure
that they won't. But, in principle, it's even better to leave them turned
on and count on the program correctness to ensure that they are never
shown.

GC> But...what about this
GC>   http://lists.nongnu.org/archive/html/lmi/2007-11/msg00004.html
GC> old discussion? I guess the thoughts I expressed there have changed
GC> because I now have more information; and it'll be clearer to address
GC> that in a separate message.

 Things have mostly changed because debugging helpers in wxWidgets 3.0
don't work at all in the same way as in the preceding versions, so quite a
few things I wrote back then are not true any more.

GC> Do you suppose we'd get a noteworthy improvement in runtime performance
GC> if we deactivated it?

 No, there wouldn't be any difference at all if you just defined NDEBUG as
this still leaves the actual code unchanged and simply disables its
effects. There would be a small difference if you rebuilt wxWidgets without
any debug support at all (--disable-debug configure option), I've observed
up to 5% improvements in the test I had done back when working on changing
this. But this was for really specific examples and "normal" code isn't
affected by the presence of debug checks/logs in it -- which is why they're
turned on by default.

 To summarize, for me the important thing was just to explain how debug
support worked now. As you understand it perfectly (as shown by this
message) and don't see anything wrong with the current behaviour, there is
nothing else to do here.

 Regards,
VZ