Re: [lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production]

[Vadim Zeitlin]

On Thu, 17 Nov 2005 06:58:06 +0000 Greg Chicares <address@hidden> wrote:

GC> > WB> Is there a real benefit to using the "debug" version versus the 
"release"
GC> > WB> version. It seems as though the debug file is 625% bigger than the 
release
GC> > WB> one:
GC> > WB> 47957kb  wxmsw26d_gcc_custom.dll
GC> > WB>  7675kb  wxmsw26_gcc_custom.dll
GC> 
GC> Vadim--Would you help me figure out whether we want '-D__WXDEBUG__'
GC> for lmi?

 I think it's a good to always build the library itself with __WXDEBUG__
defined during development as it helps to find a lot of errors in the way
wx is used much quicker.

GC> I think Wendy's earlier question concerned 'gcc -g', which
GC> is different from the question I'd like to ask here.

 It is different but still related. Because when you get assert in a
library you might need more information about why did it happen and here
the debug info can be very useful.

GC> >  Yes, gcc produces huge executables with debug.
GC> 
GC> I believe it's '-g' that makes binaries huge.

 Yes, definitely.

GC> > But using it still makes
GC> > sense because in debug build you get many checks (asserts) which help you
GC> > to detect the situations when you use the library in an invalid way.
GC> 
GC> Here I think you're speaking of __WXDEBUG__.

 Yes, absolutely.

GC> I never use facilities like wxASSERT, wxLogDebug, or wxDebugContext.

 I never use wxDebugContext myself. I do use wxASSERT (or its equivalent in
my own code -- but not standard assert which is too feature-poor compared
to wxASSERT) extensively and to be honest can't imagine living without it.
I guess you must have your reasons for not using it but I admit that I
can't really fathom them.

GC> Some of those seem to be errors I could produce by using wx incorrectly.

 Yes, most of them are.

GC> Now I'm thinking that it would always be unwise to release a system with
GC> those diagnostics suppressed.

 Normally you shouldn't use __WXDEBUG__ for production build because users
usually can't use the assertions in any meaningful way. In your case it
might be different because I presume that users have easier access to the
developers than usual so it might make sense.

GC> Why would anyone not define __WXDEBUG__ all the time? Or,
GC> alternatively, why do these safety features not use wxCHECK_MSG? I feel
GC> like I'm missing something.

 wxCHECK_MSG wouldn't change anything as they have no visible effect when
__WXDEBUG__ is not defined. They just prevent the program from crashing (or
fatally misbehaving in some other way) and where wxASSERTs are used there
is no danger of that (or you found a bug in wx).


 Anyhow, to summarize this lengthy reply, I'd recommend that:

1. you use both -D__WXDEBUG__ and -g for wx version used during development
   if possible
2. if not, still use -D__WXDEBUG__ during development
3. independently of the above, use some assert facility in lmi code

 Hope this answers your question,
VZ