[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production]
From: |
Greg Chicares |
Subject: |
[lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production] |
Date: |
Thu, 17 Nov 2005 06:58:06 +0000 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Way back on 2005-8-17 9:10 UTC, Vadim Zeitlin wrote:
> On Tue, 16 Aug 2005 21:45:34 -0500 Wendy Boutin <address@hidden> wrote:
>
> WB> Is there a real benefit to using the "debug" version versus the "release"
> WB> version. It seems as though the debug file is 625% bigger than the release
> WB> one:
> WB> 47957kb wxmsw26d_gcc_custom.dll
> WB> 7675kb wxmsw26_gcc_custom.dll
Vadim--Would you help me figure out whether we want '-D__WXDEBUG__'
for lmi? I think Wendy's earlier question concerned 'gcc -g', which
is different from the question I'd like to ask here.
> Yes, gcc produces huge executables with debug.
I believe it's '-g' that makes binaries huge.
> But using it still makes
> sense because in debug build you get many checks (asserts) which help you
> to detect the situations when you use the library in an invalid way.
Here I think you're speaking of __WXDEBUG__.
> In principle, it's possible to compile with __WXDEBUG__ defined (so that
> you get asserts) but without -g and with -O but you'd need to manually set
> up C[XX]FLAGS for this and IMHO it's not worth it.
I never use facilities like wxASSERT, wxLogDebug, or wxDebugContext.
I very rarely get memory-allocation errors. I rarely use a debugger.
The documentation seems to suggest that I might not want __WXDEBUG__.
But I have sometimes seen messages from wx when I try to do something
that doesn't make sense. Unfortunately, I can't remember anything
about the messages I have seen, except that I was very glad to get
them and they saved me a lot of time. So I grepped the wx source and
found things like this:
wxASSERT_MSG( m_frozenness > 0, _T("Thaw() without matching Freeze()") );
// this function should not be called for wxCB_READONLY controls, it is
// the callers responsability to check this
wxASSERT_MSG( !(GetWindowStyle() & wxCB_READONLY),
_T("read-only combobox doesn't have any edit control") );
wxASSERT_MSG( !IsModal(), _T("wxDialog::ShowModal() reentered?") );
wxASSERT_MSG( IsModal(), _T("EndModal() called for non modal dialog") );
wxASSERT_MSG( (0 < month) && (month <= 12), _T("invalid month") );
Some of those seem to be errors I could produce by using wx incorrectly.
Now I'm thinking that it would always be unwise to release a system with
those diagnostics suppressed. Why would anyone not define __WXDEBUG__
all the time? Or, alternatively, why do these safety features not use
wxCHECK_MSG? I feel like I'm missing something.
- [lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production],
Greg Chicares <=